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: /.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