Lock contention during automatic garbage collection in shared repositories
0 reputation · 09 Sept 2025, 04:29 UTC
0 reputation · 09 Sept 2025, 04:29 UTC
The goal is to determine whether Git's automatic garbage collector can safely run alongside concurrent fetch or push operations in a shared repository without introducing latency spikes or lock failures.
Git describes gc.auto as a threshold-based trigger, but it does not guarantee serialization of repository writes. When multiple Git processes access the same object database, automatic packfile repacking may start while another process reads or writes packs. Locking behavior varies by operating system and Git version, so it is unclear whether the collector defers to existing locks or proceeds and causes contention.
Git does not automatically serialize its garbage collection (gc) with concurrent fetch or push operations. Both processes can run in parallel, leading to potential lock contention on pack files, which manifests as temporary latency spikes or failures, not guaranteed serialization.
gc.auto to 0 disables automatic triggering, requiring manual execution during off-peak times.Contention is indicated by the presence of lock files such as .git/objects/pack/pack-*.pack.lock or pack-*.idx.lock during an operation. Stale locks from crashed processes can block subsequent access.
The necessary step to test the impact of automatic triggering is to set gc.auto to 0 per repository and then repeat the concurrent fetch/push test.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.