Git operations have a long delay in SublimeMerge

[jnns]

Version info

• OS: M3 MacBook Pro / MacOS 14.4.1.
• Build: 2091

Description

In a large repo with 60k files, Sublime Merge takes very long for most operations. For example, git stash pop works almost instantly in the command line while it takes 8 seconds in Sublime Merge.

Also very annoying and sometimes misleading is the fact, that (un)staging a file takes also around 10 seconds and the file is neither shown as staged nor unstaged during these 10 seconds.

Interestingly, SublimeMerge registers a file being (un)staged after 14 seconds when I do this via git in the command line.

It doesn't seem to be related to the .gitignore issue. I tried this with and without our project's .gitignore (around 200 lines).

It could be related to the 10 second timeout mentioned here, although moving the mouse out of the staging area doesn't do anything.

Switching between 'system' and 'bundled' git binaries doesn't change anything.

Steps to reproduce

Steps to reproduce the behavior:

1. Open a large repository (I cannot share our project unfortunately)
2. Stage or unstage a file
3. The file disappears from the view and only appears again in the expected state after a long delay.

Expected behavior

Git operation results are shown instantly in Sublime Merge.

Debug Information

Debug information

=== App Version Information ===
Build: 2091

=== Git Version Information ===
Using Git: git (system)
git version 2.44.0
PATH: ~/.pyenv/plugins/pyenv-virtualenv/shims:~/.pyenv/shims:/opt/homebrew/sbin:~/Library/Caches/fnm_multishells/55728_1712218829046/bin:~/Library/Application Support/fnm:~/bin:/opt/homebrew/bin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/usr/local/munki (from shell)
environment variables loaded using: /usr/local/bin/fish -l

=== Browse Page Information ===
HEAD: a33c9d0eebe5dc22d5fa60acbd9a09da4f65ec51
Is in merge: 0
Is in cherry_pick: 0
Is in rebase: 0
Is in revert: 0


=== Git Config Information ===
alias.cleanup=!git branch --merged | grep -v '\*' | xargs -n 1 git branch -d
alias.defaultbranch=!f() { git symbolic-ref refs/remotes/origin/HEAD | cut -d/ -f4; }; f
alias.fixup=!git log -n 50 --pretty=format:'%h %s' --no-merges | grep -v fixup | fzf | cut -c -7 | xargs -I % -o git commit --fixup % $@
alias.fixup-squash=!fzf_commit=$(git log -n 50 --pretty=format:'%h %s' --no-merges | fzf | cut -c -7) && git commit --fixup $fzf_commit && git rebase -i --autosquash $fzf_commit^
alias.pop=reset head^
alias.prdiff=!f() { cd ${GIT_PREFIX:-./}; git diff --relative origin/$(git defaultbranch)...HEAD; }; f
alias.prfiles=!f() { cd ${GIT_PREFIX:-./}; git diff --relative --name-only origin/$(git defaultbranch)...HEAD; }; f
alias.wip=!git add --all && git commit --no-verify -m wip
alias.zero=!git checkout $(git defaultbranch) && git pull --ff-only --prune && git cleanup;
blame.ignorerevsfile=.git-blame-ignore-revs
branch.esp-invalid-cups.merge=refs/heads/esp-create-account-agreements
branch.esp-invalid-cups.remote=origin
branch.esp-onboarding-errors.merge=refs/heads/esp-onboarding-errors
branch.esp-onboarding-errors.remote=origin
branch.esp-onboarding-errors.vscode-merge-base=origin/master
branch.master.merge=refs/heads/master
branch.master.remote=origin
core.bare=false
core.editor=nvim
core.filemode=true
core.fsmonitor=false
core.ignorecase=true
core.logallrefupdates=true
core.precomposeunicode=true
core.repositoryformatversion=0
credential.helper=osxkeychain
feature.manyfiles=1
filter.remove-xstate-layout.clean=sed '/@xstate-layout/d'
pull.rebase=true
push.autosetupremote=true
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*


=== Our Config Information ===
Git Config Path Information
Using config path: /etc/gitconfig
Using config path: ~/.config/git/config
Using config path: ~/.gitconfig
Using config path: <repo>/.git/config

Our config output is different to the Git config output
alias.cleanup=!git branch --merged | grep -v '\*' | xargs -n 1 git branch -d
alias.defaultbranch=!f() { git symbolic-ref refs/remotes/origin/HEAD | cut -d/ -f4; }; f
alias.fixup=!git log -n 50 --pretty=format:'%h %s' --no-merges | grep -v fixup | fzf | cut -c -7 | xargs -I % -o git commit --fixup % $@
alias.fixup-squash=!fzf_commit=$(git log -n 50 --pretty=format:'%h %s' --no-merges | fzf | cut -c -7) && git commit --fixup $fzf_commit && git rebase -i --autosquash $fzf_commit^
alias.pop=reset head^
alias.prdiff=!f() { cd ${GIT_PREFIX:-./}; git diff --relative origin/$(git defaultbranch)...HEAD; }; f
alias.prfiles=!f() { cd ${GIT_PREFIX:-./}; git diff --relative --name-only origin/$(git defaultbranch)...HEAD; }; f
alias.wip=!git add --all && git commit --no-verify -m wip
alias.zero=!git checkout $(git defaultbranch) && git pull --ff-only --prune && git cleanup;
blame.ignorerevsfile=.git-blame-ignore-revs
branch.esp-invalid-cups.merge=refs/heads/esp-create-account-agreements
branch.esp-invalid-cups.remote=origin
branch.esp-onboarding-errors.merge=refs/heads/esp-onboarding-errors
branch.esp-onboarding-errors.remote=origin
branch.esp-onboarding-errors.vscode-merge-base=origin/master
branch.master.merge=refs/heads/master
branch.master.remote=origin
core.bare=false
core.editor=nvim
core.filemode=true
core.fsmonitor=false
core.ignorecase=true
core.logallrefupdates=true
core.precomposeunicode=true
core.repositoryformatversion=0
feature.manyfiles=1
filter.remove-xstate-layout.clean=sed '/@xstate-layout/d'
pull.rebase=true
push.autosetupremote=true

=== Git Attributes Information ===
git check_attr --all output

=== Our Modified Files Newline Normalisation and EOL Information ===

=== Our Modified Files Flag Information ===
Ignoring symlinks: 0

[dpjohnst]

Hi @jnns,

Thanks for reporting this issue. I'm having trouble replicating this so far.

When you have a chance, could you run the following command on the repository in question and share the output:
git count-objects -vH

Additionally:

• When you stage / unstage / stash a file in Sublime Merge, how long does it take for the green tick to appear in the command status indicator in the UI (as shown below).
  

• Do you have any submodules (it doesn't look like it from the debug information provided)

• Do you have any git hooks enabled for this repository

• Does the same slowdown happen when there is only a single modified / staged file in the repository

• Do you get the same performance on the command line after running git config --unset feature.manyFiles (after testing this, run git config feature.manyFiles 1 to revert back to the original config setting).

[jnns]

Hi Dylan,

thank you for looking into this.

$ git count-objects -vH
count: 1430
size: 6.19 MiB
in-pack: 5902903
packs: 20
size-pack: 2.77 GiB
prune-packable: 39
garbage: 0
size-garbage: 0 Bytes

• It's behaving weirdly. When I stage/stash something, there's a brief change from check mark to circle (just a split second). Then it takes roughly 12-20 seconds until the changes are reflected in the UI and at that moment the status indicator once again briefly switches to the circle (but not always).

• Hooks are enabled but even with disabled hooks the symptoms are the same. (I renamed .git/hooks temporarily to test this).

• There are no submodules involved.

• The slowdown happens always, no matter how many files are changed/stashed/staged. Even with a single file.

• feature.manyFiles has no impact on the speed of the git command line. It's fast in both setting states.

[BarabasGitHub]

Are you running any anti-virus software? I have similar issues and I'm 99% sure it's my antivirus software at work. I tried it on another pc without the anti-virus and it's 10x faster.

[jnns]

No, I'm not running anti-virus software on my laptop.

[jnns]

Maybe helpful for debugging:

When I begin the process of committing a change in Sublime Merge by staging a file, but then switch to the command line because it just takes too long, the CLI will show the file as staged whereas the staging is not yet reflected in Sublime Merge. I then continue by running git commit and finish my changes. Sublime Merge then updates its state by showing the already committed file as staged. A few seconds later, Sublime Merge also registers the commit having happened already and shows it.

[dpjohnst]

Hi @jnns,

Just following up on this - I haven't had any luck reproducing this issue despite multiple attempts.
I'm going to try and determine if it's purely a UI issue or a repository reading issue.

To validate this, could you perform the following steps:

1. Stage some files
2. Wait until they appear in the staging area
3. Unstage some files
4. Promptly navigate to Help > Debug Information (prior to the unstaged files appearing in the modified files section)
5. Paste the debug information into a text editor
6. At the bottom of the debug information, there will be a section called === Our Modified Files Flag Information ===. Could you confirm if none / some / all of the unstaged files are present in this section?

Thanks for your help and patience while we get this resolved.

Kind regards,
- Dylan from Sublime HQ

[jnns]

Hi Dylan,

thanks for your effort in reproducing this. This is the debug information prior the unstaged file appearing in the working directory area again:

[...]
=== Git Attributes Information ===
git check_attr --all output

=== Our Modified Files Newline Normalisation and EOL Information ===

=== Our Modified Files Flag Information ===
Ignoring symlinks: 0

[jnns]

I tried to find a public repository that matched the size of our project (1M files, 400K commits, 12GB). I assume that the delay is caused by the size of the file tree and that Sublime Merge maybe has to scan every folder for changes?

Although the effects are not as drastic, the delay is reproducible with the Chromium repository:

❯ git clone https://github.com/chromium/chromium.git --depth=1
❯ cd chromium
❯ find . -type f | wc -l
  443313 
❯ smerge .

Wait till Sublime Merge is ready. Then create a new file:

❯ touch hello-world.txt
❯ git status

Git will show the new file instantly, while the Sublime Merge window will only display the new file after ~15 seconds.

The same phenomenon appears when staging the file in Sublime Merge: running git status in a terminal on the side shows the file instantly as staged while it takes more than 10 seconds for the file to be marked as staged in Sublime Merge. Just as with unstaging the file again.

Please note that I need git config core.fsmonitor true for git status to return something instantly. Without that flag, it takes 3 seconds.

[dpjohnst]

Hi @jnns,

Thanks for the additional information. I've now been able to partially reproduce the issue and will be working on addressing this.

Many thanks,
- Dylan from Sublime HQ

[jnns]

Thank you so much Dylan! I'm looking forward to be able to use Sublime Merge again with that repo. Other GUI clients don't come close.

[jnns]

Hi @dpjohnst,

can you foresee whether this issue is fixable? I'm currently torn between sticking with Sublime Merge because working with it will eventually be smooth sailing again, or whether I should pick up a new GUI. Thanks!

[dpjohnst]

Hi @jnns,

Thank you for your patience while we work on resolving this. We're still in the process of resolving this issue but it should be fixed in the next release.

Cheers,
- Dylan from Sublime HQ