Long git log calls on large repos (like Chromium), high CPU

[jasonwilliams]

Description

On a large repository my CPU is often spinning up and its always the Git process running. When tracing this back it seems to be coming from this command within VS Code's process explorer:

git.exe -c core.longpaths=true -c core.quotepath=false -c color.ui=false -c log.showSignature=false -c diff.renameLimit=0 log --format=%x3c%x2ff%x3e%n%x3cr%x3e%x20%H%n%x3ca%x3e%x20%aN%n%x3ce%x3e%x20%aE%n%x3cd%x3e%x20%at%n%x3cn%x3e%x20%cN%n%x3cm%x3e%x20%cE%n%x3cc%x3e%x20%ct%n%x3cp%x3e%x20%P%n%x3cs%x3e%n%B%n%x3c%x2fs%x3e%n%x3cf%x3e -M --name-status --full-history -m --no-min-parents -n3 4ae8534647734926ea3f921d38aabecede71fa02 --

On my laptop this command can take around 5 minutes to run, even worse this command can be spawned multiple times so I can sometimes have 3 or 4 of these running (and that's where the high CPU usage comes from).
After some back and forth reproducing its the --full-history flag that seems to be causing the issue on a large repo it seems to be bringing up a lot of large commits.

Doing some diggin on this repo I can see that --full-history is called here:
https://github.com/gitkraken/vscode-gitlens/blob/main/src/env/node/git/sub-providers/commits.ts#L301

It looks like this is mainly executed when a line in the file is selected (I assume to get the git annotation), here is a stack trace:

- CommitsGitSubProvider.getLog (env\node\git\sub-providers\commits.ts:198)
- descriptor.<computed> (system\decorators\log.ts:114)
- CommitsGitSubProvider.getCommit (env\node\git\sub-providers\commits.ts:59)
- descriptor.<computed> (system\decorators\log.ts:114)
- <anonymous> (git\gitProvider.ts:630)
- GitCommit(c:/dev/chromium.bb|c9135bf).ensureFullDetails (git\models\commit.ts:255)
- descriptor.value (system\decorators\-webview\gate.ts:31)
- LineAnnotationController.refresh (annotations\lineAnnotationController.ts:251)

First question, why is full-history needed here? Can we get away without needing that flag? If its just for blame or the line annotation can we achieve this without traversing the entire history?

Is this cached?

The caching behavior of this is a bit weird, it does seem cached, for example if i hit another line in the file it does seem to use the cache, but not always, even if i don't make any changes to the file sometimes it needs to fetch the data again or if i scroll down a big file and click another line it needs to re-fetch So I don't know what the cache policy is. Looking at where the cache is fetched it does seem to be based on the file itself, so I don't know why multiple clicks on different lines would invalidate the cache.

Second question, are only the lines in the viewport cached? Or is it only caching lines down to a point?

It may be me not understanding the codebase very well here, but even though getBlameForLine receives a cached value it still ends up calling getCommit which triggers another full git log. I think @eamodio will know more about how this all works

Third Question
I wonder if there can be some UX/Performance compromise here. For instance if it’s spending time getting the full log and I click another line, should there be a second process? I would rather not have a git annotation than have another process spin up for 5 minutes.

I believe there is already logic to “wait”, so I’m not sure why it isn’t taking effect all the time.

GitLens Version

16.3.0

VS Code Version

Version: 1.97.2 (user setup)
Commit: e54c774e0add60467559eb0d1e229c6452cf8447
Date: 2025-02-12T23:20:35.343Z
Electron: 32.2.7
ElectronBuildId: 10982180
Chromium: 128.0.6613.186
Node.js: 20.18.1
V8: 12.8.374.38-electron.0
OS: Windows_NT x64 10.0.19045

Git Version

git version 2.43.0.windows.1

Logs, Screenshots, Screen Captures, etc

No response

[jasonwilliams]

Related: #4115

On each file change the bottom right status bar does a full fetch of git commit history. There’s no way to defer this (as it powers the hover) so instead this provides an option to switch that feature off