Unresponsive "commits" view and "branches" view update due to git log

[wro-ableton]

Description

In some cases, the commits and branches view becomes really unresponsive and takes a long time to update. It seems that on one branch, it takes up to a minute to perform the following call on a forced commits view refresh:

git log --format=<format> -M -m --name-status --full-history -n41 <my_branch> -- (Will take 58106ms)

I've tried to reproduce this by copying the command and it seems to only take long when I increase the diff.renameLimit. By default with my config, this call instead gave me a warning: inexact rename detection was skipped due to too many files. warning.

The repository is not open source.

GitLens Version

13.2.0

VS Code Version

Version: 1.74.3 (user setup)
Commit: 97dec172d3256f8ca4bfb2143f3f76b503ca0534
Date: 2023-01-09T16:59:02.252Z
Electron: 19.1.8
Chromium: 102.0.5005.167
Node.js: 16.14.2
V8: 10.2.154.15-electron.0
OS: Windows_NT x64 10.0.19043
Sandboxed: No

Git Version

git version 2.28.0.windows.1

Logs, Screenshots, Screen Captures, etc

No response

[eamodio]

@wro-ableton When you run git log --format=<format> -M -m --name-status --full-history -n41 <my_branch> -- from the terminal you see it take ~58s or only from GitLens? If you run the same command without the -m and/or the -M (my guess it would be the -M causing the slowdown) does it still take as long?

[wro-ableton]

Hey, thanks for the quick reply!
When I set the diff.renameLimit to a large enough number for git not to complain about the rename detection, removing the -m option will speed up the call to bascially an instant response. However, removing -M doesn't seem to speed up the call at all.

And yes, when I run the command in my terminal, it also takes that lone when I have the diff.renameLimit high. Is GitLense using it's own git configuration?

[eamodio]

Wow the -m huh. Wouldn't have guessed, do you have many large merge commits?

Yeah GitLens sets diff.renameLimit=0

[wro-ableton]

Not really. I think the merge commits should be the the ball park for what's to be expected from a commercial repositories with ~100 collaborators.

[eamodio]

Sorry for the long delay on this one. If you can, could you please verify this fix in tomorrow's (v2023.11.27xx) pre-release edition of GitLens? Thank you so much!

You can switch to the pre-release edition of GitLens, by clicking on the "Switch to Pre-Release version of this extension" from the Extensions view.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.