git-lfs stage very slow in sourcetree
Asked by Ryan Parnell:

repo with git-lfs enabled takes FOREVER to stage and un-stage files within sourcetree, but not with git command line or even vs.net

windows x64 sourcetree v1.9.5


Answers:
author: UnderminerStudios
body: Actually it appears that the issue is SourceTree uses git 32 bit instead of the 64 bit version. Why isn't it allowing us to actually use our version of git-lfs. It seems to revert to the embeded version.


author: Adam Tween
body: We're having the same issues. Hopefully an end is in sight:

<https://jira.atlassian.com/browse/SRCTREE-4363>

*"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."*


author: Dave_
body: 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).

<https://github.com/git-lfs/git-lfs/issues/1750>

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.

comments: author: UnderminerStudios
body: This doesn't happen in command line though and isn't source tree just a visual on top of the command line? I can even press the command line option inside of source tree and it's fine. Not sure if it isn't a Source Tree only issue.


author: Dave_
body: @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:

<https://github.com/git-lfs/git-lfs/pull/1616>

and

<https://github.com/git-lfs/git-lfs/issues/1750>

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.


author: yfede
body: Same problem here, and I'm on Mac with SourceTree version 2.3.2


author: Oz Solomon
body: David if you have a public link to the bug can you post it so we can track?


author: Dave_
body: 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?


author: emiliodirita2
body: I confirm that stage is always slow, also with 1.9.10 update.

Now it takes forever for stage.


author: Andrew Sasak
body: This seems like its attempted to be resolved in 1.9.10, but still occurs


author: Andrew Sasak
body: I'm using system Git instead of embedded Git with sourcetree and experience this. I don't know why SourceTree is explicitly doing anything with lfs. Everything should happen automatically via git.


author: Ryan Parnell
body: 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."


author: Dave_
body: My team just started using LFS in our main repo and sourcetree is extremely slow to stage files. We haven't tried to find a workaround yet, but I wanted to put my name on the list of people experiencing this.


author: Andrew Sasak
body: This just started for me after either upgradnig lfs or more likely doing a "git lfs uninstall" and then "git lfs install". I'm staging non-lfs files and "git lfs track" is taking a tremendous amount of tmie and cpu to process before the file is staged.


author: Soloman Northrop
body: Same problem here guys. Any solution?


author: emiliodirita2
body: Same problem.

windows x64 sourcetree v1.9.6.1


author: jrobe
body: I have the same thing, extremely slow. Also, it looks like it's doing a git status repeatedly, meaning I can't select things to stage either.


Tags: git-lfs