staging hunks or files is slow in a large repo

[mattnworb]

Describe the bug

A clear and concise description of what the bug is.
We have a large-ish repo (275k files) and I've noticed that staging files or hunks in a file can be quite slow, without much feedback in the UI on what is happening.

lazygit --debug and --logs suggest it has to do with the operation involving a git status --untracked-files all call:

Mar 31 15:32:43 |INFO| saving temporary patch to /var/folders/m1/5018nxw5655fd55ql3xqqpjm0000gn/T/lazygit-501/lazygit-3047562716/some-project/Mar 31 15.32.43.607242000.patch
Mar 31 15:32:43 |INFO| RunCommand command="Creating file '/var/folders/m1/5018nxw5655fd55ql3xqqpjm0000gn/T/lazygit-501/lazygit-3047562716/some-project/Mar 31 15.32.43.607242000.patch'"
Mar 31 15:32:43 |DEBU| RunCommand command="git apply --cached \"/var/folders/m1/5018nxw5655fd55ql3xqqpjm0000gn/T/lazygit-501/lazygit-3047562716/some-project/Mar 31 15.32.43.607242000.patch\""
Mar 31 15:32:43 |INFO| git apply --cached "/var/folders/m1/5018nxw5655fd55ql3xqqpjm0000gn/T/lazygit-501/lazygit-3047562716/some-project/Mar 31 15.32.43.607242000.patch" (111.865ms)
Mar 31 15:32:43 |INFO| refreshing the following scopes in sync mode: files,staging
Mar 31 15:32:43 |DEBU| using cache for key status.showUntrackedFiles
Mar 31 15:32:43 |DEBU| RunCommand command="git status --untracked-files=all --porcelain -z --find-renames=50%"
Mar 31 15:32:43 |INFO| refreshed merge conflicts in 671.875µs
Mar 31 15:32:47 |INFO| git status --untracked-files=all --porcelain -z --find-renames=50% (3.732384s)
Mar 31 15:32:47 |INFO| refreshed files in 3.799649541s
Mar 31 15:32:47 |DEBU| RunCommand command="git -C /Users/mattbrown/code/some-project/worktree1 diff --no-ext-diff --submodule --unified=3 --color=never --find-renames=50% -- README.md"
Mar 31 15:32:47 |INFO| git -C /Users/mattbrown/code/some-project/worktree1 diff --no-ext-diff --submodule --unified=3 --color=never --find-renames=50% -- README.md (175.33525ms)
Mar 31 15:32:47 |DEBU| RunCommand command="git -C /Users/mattbrown/code/some-project/worktree1 diff --no-ext-diff --submodule --unified=3 --color=never --find-renames=50% --cached -- README.md"
Mar 31 15:32:47 |INFO| git -C /Users/mattbrown/code/some-project/worktree1 diff --no-ext-diff --submodule --unified=3 --color=never --find-renames=50% --cached -- README.md (93.288291ms)
Mar 31 15:32:47 |DEBU| RunCommand command="git -C /Users/mattbrown/code/some-project/worktree1 diff --no-ext-diff --submodule --unified=3 --color=never --find-renames=50% -- README.md"
Mar 31 15:32:47 |INFO| git -C /Users/mattbrown/code/some-project/worktree1 diff --no-ext-diff --submodule --unified=3 --color=never --find-renames=50% -- README.md (76.490459ms)
Mar 31 15:32:47 |DEBU| RunCommand command="git -C /Users/mattbrown/code/some-project/worktree1 diff --no-ext-diff --submodule --unified=3 --color=never --find-renames=50% --cached -- README.md"
Mar 31 15:32:47 |INFO| git -C /Users/mattbrown/code/some-project/worktree1 diff --no-ext-diff --submodule --unified=3 --color=never --find-renames=50% --cached -- README.md (85.516833ms)

this in a repo with git maintenance enabled, core.fsmonitor=true, feature.manyfiles=true etc. time git status generally takes 300ms in this repo.

is refreshing the status of untracked files necessary when staging hunks in a tracked file?

To Reproduce

Steps to reproduce the behavior:

1. find a large repo
2. create a few unstaged changes in tracked files
3. run lazygit and attempt to stage either whole files or hunks in a file

Expected behavior

Ideally staging individual hunks in a file would not have a several second delay in between each operation, as there are often multiple hunks to stage.

Version info:

❯ lazygit --version
commit=, build date=, build source=Homebrew, version=0.60.0, os=darwin, arch=arm64, git version=2.53.0

Terminal info:

Ghostty 1.3.1

[stefanhaller]

You should be able to improve performance by doing git config status.showUntrackedFiles no. Of course this means you will never see untracked files any more, so this might not be an acceptable workaround.

is refreshing the status of untracked files necessary when staging hunks in a tracked file?

Good question; it feels like it shouldn't be. However, it would require a bit of work to avoid it; we'd have to take over the untracked files from the previous state of the model. I'll look into it when I find some time (might not be soon).

In general you might ask why we are doing a refresh of the files panel at all when staging hunks; this is necessary for the following cases:

• staging the first hunk of a tracked file turns M into MM
• staging the last hunk of a tracked file turns MM into M
• staging the first hunk of an untracked file turns ?? into AM
• staging parts of a renamed file might turn R into a pair of A and D or v.v.

And maybe others that I forgot right now. It might be possible to anticipate some of these and change them in our model without asking git, but that's error-prone, and I'm worried that we miss some cases and display stale information.