TortoiseGit .gitconfig integrity during interrupted upgrade
0 reputation · 10 Oct 2023, 16:37 UTC
Configuration state after mid-write failure
TortoiseGit stores user-level settings in %USERPROFILE%\.gitconfig and supplements them with UI-specific data under %APPDATA%\TortoiseGit. The installer writes to these locations during upgrade, but the MSI transaction does not treat the text-based .gitconfig as a rollback-capable resource.
Observed gap
When an upgrade is interrupted — for example, by a forced reboot or MSI error — the installer’s rollback restores registered files and registry keys, yet any partial writes to .gitconfig remain. This can leave the file with duplicate sections, truncated values, or malformed syntax that Git for Windows then reads on the next invocation.
No documented mechanism describes how TortoiseGit detects or repairs such corruption on first launch after a failed upgrade. The embedded git.exe binary also lacks a built-in validator for the user configuration file.
Open questions
- Does TortoiseGit perform any integrity check or automatic repair of
.gitconfigat startup following a detected upgrade failure? - If the file is left malformed, what is the expected fallback behavior — does the shell extension load defaults, surface an error dialog, or silently ignore the broken sections?
- Are there version-specific differences (2.x vs 3.x) in how the installer sequences writes to
.gitconfigversus the registered application paths?