git-lfs stage very slow in sourcetree

[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

[UnderminerStudios]

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.

[Adam Tween]

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

[Dave_]

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.

[UnderminerStudios]

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.

[Dave_]

@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.

[yfede]

Same problem here, and I'm on Mac with SourceTree version 2.3.2

[Oz Solomon]

David if you have a public link to the bug can you post it so we can track?

[Dave_]

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?

[emiliodirita2]

I confirm that stage is always slow, also with 1.9.10 update.

Now it takes forever for stage.

[Andrew Sasak]

This seems like its attempted to be resolved in 1.9.10, but still occurs

[Andrew Sasak]

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.

[Ryan Parnell]

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

[Dave_]

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.

[Andrew Sasak]

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.

[Soloman Northrop]

Same problem here guys. Any solution?

[emiliodirita2]

Same problem.

windows x64 sourcetree v1.9.6.1

[jrobe]

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.