What did you do before the bug happened?
On Windows, a repository on an SMB share mapped to a drive letter (P: = file://192.168.56.101/TestDir, Samba on a VM; files are owned by a different SID than the current user) is used with a global config that lists several safe.directory entries. One entry points to a UNC path on a host that is currently not reachable:
git config --global --add safe.directory \ '//192.168.1.190/dummy-test/repo.git'
cd P:\ git status
What did you expect to happen?
An entry that cannot match the repository being opened should not slow down the command. "git status" should take about 2 s, as it does without the entry.
What happened instead?
The first "git status" takes about 29 s. Repeated runs shortly afterwards take about 1.8 s (Windows seems to cache the failed host lookup for a while). Removing the single unreachable entry from the global config brings the first run down to about 2.3 s.
Timings (same repo, same session): with unreachable safe.directory entry: 29.07 s, 1.93 s, 1.78 s entry removed: 2.27 s, 1.58 s
GIT_TRACE2_PERF shows the time is spent before the worktree is set up, with no git work in between:
13:43:00.798 main ancestry: git.exe, powershell.exe, ... 13:43:21.973 main worktree://192.168.56.101/TestDir (exit after 26.2 s total, of which about 5 s are git work)
A plain filesystem probe of the dead host root from PowerShell (Test-Path '//192.168.1.190/dummy/') also takes about 25 s to fail, so the wait appears to be the Windows network connect timeout.
My hypothesis, not verified in the source: the configured safe.directory values are normalized (resolved to a real path) when checked, which makes Windows contact the unreachable host. The ownership check is only done when the repository is not owned by the current user, which is always the case on this share. Comparing the entry against the repository path first, and only resolving entries that could match, would avoid contacting unrelated hosts.
Impact: tools that run git often, such as TortoiseGit, pay the delay repeatedly (our Commit dialog took ~30 s to update). Stale entries for old or offline network locations are common, so this is easy to hit.
What's different between what you expected and what happened?
An unrelated, unreachable safe.directory entry makes git commands wait about 25 s.
Anything else you want to add:
Reproduced with Git for Windows 2.56.0.windows.2 and 2.46.1.windows.1. Related reports (not the same problem): https://github.com/git-for-windows/git/issues/5673 https://github.com/git-for-windows/git/issues/6359
[System Info] git version: git version 2.56.0.windows.2 cpu: x86_64 built from commit: cc4dbf752a05efdc0e04e71fd3e8110d11bdd35c sizeof-long: 4 sizeof-size_t: 8 shell-path: D:/git-sdk-64-build-installers/usr/bin/sh rust: disabled feature: fsmonitor--daemon gettext: enabled libcurl: 8.22.0 OpenSSL: OpenSSL 3.5.9 29 Sep 2026 zlib: 1.3.2 SHA-1: SHA1_DC SHA-256: SHA256_BLK default-ref-format: files default-hash: sha1 uname: Windows 10.0 26200 compiler info: gnuc: 16.2 libc info: no libc information available $SHELL (typically, interactive shell): C:\Programs\Git\usr\bin\bash.exe
Best regards
Daniel Gullberg 3M Personal Safety Division | Welding Center of Excellence 3M Svenska AB, Ernst Hedlunds v.35 | 785 30 Gagnef | Sweden Time: GMT +1:00 mailto:daniel.gullberg@mmm.com