git-lfs stage very slow in sourcetree

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

16 answers

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.

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.

Same problem.

windows x64 sourcetree v1.9.6.1

Same problem here guys. Any solution?

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.

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.

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

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.

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

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

Now it takes forever for stage.

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?

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

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

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

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.

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.

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

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Oct 23, 2018 in Sourcetree

Tip from the team: configure your repos for hosting goodness!

Supported Platforms macOS Windows We recently introduced support for additional hosting services such as GitHub Enterprise, GitLab (Cloud, Community Edition, Enterprise Edition), and...

718 views 3 2
Read article

Atlassian User Groups

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!

Find my local user group

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

Groups near you