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.