Uploaded image for project: 'Sourcetree For Mac'
  1. Sourcetree For Mac
  2. SRCTREE-6538

Sourcetree is painfully slow when dealing with large changes / repos

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Medium Medium
    • None
    • None
    • General
    • None
    • Sourcetree 3.0.1

    • Severity 2 - Major

      For some reason our repo performs terribly with Sourcetree - when dealing with staging/unstaging/resetting files with large sets of changes it is almost unusable due to endless loading spinners. It seems to be constantly hanging while talking to git and refreshing.

      Our repo is reasonably unique but I have seen this with other repositories in the past and it's an ongoing issue with sourcetree. More and more I'm returning to the command line to do stuff. e.g. stashing - It's just SO slow with sourcetree to stash, switch branch and then pop.

      I would love to see Sourcetree double down on becoming a lightning fast experience that is comparable to the command line, especially in complex situations which is where I need it most!

       

      A bit about the current repo I am dealing with:We store a lot of pngs in the repo (for ui verification) but we chose not to bloat git itself with binaries, so we opted to use git-lfs for the storage of these. We store a number of other binaries that rarely change in the repository in the same way. We have reasonably complex pre-commit checks set up Otherwise the only other thing I can think of is we have a single (small) submodule attached to the project.

      Breakdown of my local .git directory is:

       
      Size

      Size Directory
      714M ./objects
      664K ./info
      380K ./logs 
      80K   ./hooks
      15M  ./worktrees
      844K ./refs ./refs
      1.0G ./lfs ./lfs
      0B  ./branches
      2.7M  ./modules

       

              Unassigned Unassigned
              b4a35c0be013 Sam Duke
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated: