You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Cache typed config with git config list --type=<X> (#2268)
In certain repos and on the Windows platform, `git-credential-manager`
can take 8-15 seconds before looking up a credential or having any
user-facing interaction. This is due to dozens of `git config --get`
processes that take 150-250 milliseconds each. The config keys that
cause this pain are `http.<url>.sslCAinfo` and `http.<url>.cookieFile`.
When `credential.useHttpPath` is enabled, each key is checked as `<url>`
is incrementally truncated by directory segment.
It would be best if we could call a single Git process to send multiple
config queries instead of running multiple processes.
gitgitgadget/git#2033 suggested this direction of a single process
solution, but it's very complicated! During review of that effort, it
was recommended to use `git config list` instead.
But then there's a different problem! In all released versions of Git,
`git config list` silently ignores the `--type` argument. We need the
`--type` argument to guarantee that the resulting output string matches
the `bool` or `path` formats.
The core Git change in gitgitgadget/git#2044 is now merged to `next` and
thus is queued for Git 2.54.0. (We should wait until it merges to
`master` before merging this change, just in case.) We can only check
compatibility using a version check since the original command silently
misbehaves.
This pull request allows for caching the list of all config values that
match the given types: bool, path, or none. These are loaded lazily so
if a command doesn't need one of the types then the command doesn't run.
We are also careful to clear this cache if GCM mutates the config.
Since we ask for Git config values using `--type=bool`, `--type=path`,
_and_ `--no-type`, we may launch three `git config list` commands to
satisfy these needs.
There is a possibility that this feature is fast-tracked into
microsoft/git, in which case the version check would need augmentation.
I have that available in derrickstolee#1 as
an example.
Disclaimer: I used Claude Code and GitHub Copilot CLI to assist with
this change. I carefully reviewed the changes and made adjustments based
on my own taste and testing.
I did an end-to-end performance test on a local monorepo and got these
results for improvements to no-op `git fetch` calls:
| Command | Mean [s] | Min [s] | Max [s] | Relative |
|:---|---:|---:|---:|---:|
| Without Cache | 14.986 ± 0.255 | 14.558 | 15.192 | 3.29 ± 0.17 |
| With Cache | 4.561 ± 0.223 | 4.390 | 4.935 | 1.00 |
0 commit comments