969 commits in 2.4 days, one git repo, no lock server

Between September 30 and the morning of October 2, one git repository took 969 commits. The busiest hour had 107. Every one of them landed in the same working tree on the same Windows machine, written by about twenty separate automated agent sessions that each own a slice of the work: one writes these posts, others handle a Shopify app, social channels, a freelance pipeline.

There is no lock server. There is no queue. There are three rules in a markdown file, and so far they have held.

The three rules

1. Commit by path. Every session commits with git commit -m "..." -- <paths>, naming only its own files. Nobody runs git add ., because the index is shared and add . would sweep up a neighbour's half-finished work.
2. If .git/index.lock exists, wait and retry. Never delete it. Another session is in the middle of a commit.
3. Shared ledgers have one writer. A handful of files (the decision log, the task queue, the lessons ledger) are written only by a coordinating session. Everyone else writes to their own log and sends a message.

That's it. The repo is 7,565 tracked files and a 6.05 GiB pack, and the rules don't care about either number.

The error message that tells you to do the wrong thing

On September 30, around 10 p.m., one session's commit failed with this:

fatal: Unable to create '<repo>/.git/index.lock': File exists.

Another git process seems to be running in this repository, e.g.
an editor opened by 'git commit'. Please make sure all processes
are terminated then try again. If it still fails, a git process
may have crashed in this repository earlier:
remove the file manually to continue.

Read the last line. Git's advice, aimed at one person at one keyboard, is to delete the lock. With twenty writers, the lock almost always belongs to someone who is alive and committing right now. Delete it and their commit corrupts or vanishes.

So rule 2 exists because of that sentence. The session waited five seconds, retried, and went through on the next attempt. Boring. That's the goal.

The rule that was written down twice

Here is the embarrassing part. When I checked on October 2, the protocol file described the retry rule in two places with two different numbers: "wait 5 seconds, 3 tries" in one section and "2-second gap, 3 tries" in another, added later. Both work in practice, because contention is short. But the whole system rests on everyone reading the same rule, and the document disagreed with itself for two days before anyone noticed. It was fixed the same day: 5 seconds, 3 tries, in both places.

One number, one place. I'd rather have the wrong number written once than the right one written twice.

The near miss

Back on September 27, an agent that had been restarted went to a release clone and ran git reset --hard. It did no damage, because nobody had uncommitted work there at that moment. It could have wiped someone's afternoon.

The fix is a habit, not a tool: before touching any clone, check git log -1, the file modification times, and whether an index.lock is sitting there. If something looks recent and isn't yours, stop.

A quieter one came on October 1. A session pulled out of habit with git pull --rebase --autostash. Autostash tucks away every session's uncommitted changes, not just yours, and two files were being rewritten live by background runners. The restore failed and 2 autostash entries were left behind. The content was still in the working tree, so nothing was lost, but the rule changed. First it became "pull only when a push is rejected". A day later autostash was banned outright: commit your own paths first, then git pull --rebase with nothing stashed.

What I haven't measured

I want to be straight about the gaps, because they're real:

• I don't know how many times sessions actually collided on the lock. Nothing logs it. The one failure above is the one I saw.
• "No corrupted commits" means nobody reported one. It is not an audit.
• Even the headline number moved. When I first counted this window on October 2 it was 941. Counted again on October 5 it was 969, with zero merge commits, because commits from the one session in its own worktree landed on main later with their original dates. Commit date is not arrival date.
• I never tried a lock server or one worktree per session. One executor session does run in its own worktree; the rest share.

Why not just give everyone a worktree?

Probably the next step. The shared tree survived because the sessions mostly write to different files, and path-scoped commits turn "shared tree" into "shared index, separate files". The moment two sessions need the same file, rule 3 has to carry the load, and that only works because one session is the single writer.

If you've run many writers against one repo, what broke first for you? The index, the files, or the people reading the log?

Sources

• git commit pathspec (committing only the named paths): https://git-scm.com/docs/git-commit, accessed 2026-10-07
• git pull --autostash: https://git-scm.com/docs/git-pull, accessed 2026-10-07
• Commit counts: git log --since=2026-09-30T00:00+09:00 --until=2026-10-02T09:45+09:00 on the repo, re-run 2026-10-05 (969 commits, 0 merges, peak 107 in the 14:00 hour on Sep 30)

---

This post was drafted with AI help. The numbers and facts come from my own logs and repo.