As a follow up to my original post, I just updated SourceTree this morning. I also updated to the latest Git and Git LFS. After some struggles with conflicts from earlier versions of SourceTree still on my system (I guess they don't automatically remove them) I got SourceTree running. Unfortunately, SourceTree claimed I didn't have LFS installed ... "would I like to install it?".
After some googling I found that SourceTree for mac has this trouble (I use Win10). They stated that SourceTree wasn't honoring PATH, so their solution was to create a symbolic link within the Git bin directory to the GitLfs.exe file. Here's the command I ran to get path SourceTree's insistence that I didn't have GitLfs installed:
mklink /h "C:\Program Files\Git\mingw64\bin\git-lfs.exe" "C:\Program Files\Git LFS\git-lfs.exe"
With high hopes, I went to test LFS staging speed again, thinking that maybe before I was using the SourceTree version of LFS instead of the version I had previously installed to my system. Unfortunately, it was still slow. I'm still hoping this will be addressed in the near future. I hate having to keep telling my team "There's a bug in SourceTree that they haven't fixed yet."
For those of you having this issue, I'd recommend opening an actual bug report with Atlassian. I did that a few days ago and they've asked me for some additional logging which I'm working on pulling for them. Maybe if enough bug reports are opened it'll get some action.
I believe the issue may be that I'm on a many-years-old repository with lots of branches and a ton of tags. Can anyone else confirm a similar repo situation? Has anyone seen this on a relatively young repo with few commits/branches/history?
@Oz Solomon - I just checked and it turns out my bug report is private, not public. However...
By following the instructions the support person sent me to enable logging in ST, I confirmed that "git lfs track" is the culprit on my system. The ST logs said that command took about 45 seconds. I confirmed it took close to 40 in a git-bash window.
My theory (unconfirmed) is that ST runs this to see which files should be tracked and uses that information when staging a file to prompt you "This file is huge, do you want to LFS it?"
That knowledge led to some googling which found these two bugs:
The first one was merged but still had some issues. The second one seems to have uncovered more of the real problem and is still under development. I've posted a comment there asking for any short-term workarounds.
I've also sent this info to the ST support ticket I had opened and asked about a way to disable the "git lfs track" execution on every stage. I'll post back here if anything changes.
Based on the comments in the bug report below at the git-lfs project I think the issue is that 1) SourceTree calls `git lfs track` when staging files and 2) `git-lfs.exe` has performance issues on some large repositories with extensive .gitignores (to paraphrase the root-cause from the git-lfs bug report).
The git-lfs folks on that ticket have a fix that will be out soon (early 2017?) that fixes the issue. I have tried pulling down a build of their new version and it works for me on my system. The notes on how to do this are in the comments on that ticket if you're adventurous.
We're having the same issues. Hopefully an end is in sight:
"We'll be rolling out another build this week with the latest Git-LFS (1.5.4) and Bitbucket Media Adapter (1.0.4) embedded and they are focused on performance improvements."
Supported Platforms macOS Windows We recently introduced support for additional hosting services such as GitHub Enterprise, GitLab (Cloud, Community Edition, Enterprise Edition), and...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs