A repository whose metadata directory is bind-mounted into more than one execution context (a host and the container built from it, say) does not have two git configurations. It has one file, visible through two doors. A persistent configuration write made from either side changes what the other side reads, and nothing about making the write announces that it did.
Why this is easy to miss
The two contexts usually need different settings for the same purpose. A credential helper that resolves correctly from inside a container is often meaningless from the host’s own execution context, and the reverse holds just as often: a path, a script, a helper that exists on one side and simply isn’t there on the other. Each side’s fix looks completely local: change a setting where the problem is happening, verify it there, move on. But there was never a second file for the fix to be local to.
Check before you write, not after it breaks
Before any persistent change to a repository’s configuration, establish whether its metadata directory is mounted into more than one execution context. The check is direct: compare the device and inode reported for the configuration path from each candidate context. If they match, there is one file behind both doors, and a persistent write from either side is a write to both.
The safer pattern: per invocation, not persisting either
Where two contexts genuinely need different settings, the fix isn’t to pick a winner and persist it: that only relocates the next collision to whichever side didn’t get chosen. Supply the setting per invocation instead: pass it as an override on each command, clearing any inherited value first, rather than writing it into the shared file at all. Neither side’s need survives past the command that needed it, and neither side can silently overwrite the other’s.
A separate, smaller claim: hand-triggered is not unattended
A mechanism proven by triggering it by hand has not been proven to run unattended. A push, a job, a scheduled task that succeeds every time a person sets it off directly can still fail every time it’s supposed to fire on its own: a different execution context, a missing prompt, a scheduler with no one behind it to answer what a human would have answered without noticing. Proving the unattended path means watching the unattended path actually run, not standing next to it and running it yourself.
The night this came from, told as it happened, is Act 26: One file, seen from two sides.