The Lockfile That Wasn't There
Git worktrees promise parallel builds without the disk overhead of multiple clones. Run git worktree add ../feature-branch and you've got a second working directory sharing the same .git — perfect for testing a hotfix while keeping your main branch clean, or running CI checks without stopping your current work.
Until both worktrees try to write at the same time.
I hit this building a CI pipeline that tested multiple branches concurrently. The idea was simple: spin up three worktrees, run pytest in each, collect results. Worked great locally with sequential runs. In CI with parallel jobs? Random failures with error: could not lock config file .git/config: Resource temporarily unavailable. Not every run. Just often enough to make the build unreliable.
The problem isn't obvious from the docs. Git worktrees share more than just objects — they share the index update logic, reflog writes, and config file access. Most of these operations use lockfiles (index.lock, HEAD.lock, config.lock), but the locking is optimistic: Git assumes you're not hammering the same repo from multiple processes simultaneously. Worktrees break that assumption.
Continue reading the full article on TildAlice
Top comments (0)