Comment by Sneha M K on "One Index, Many Writers: Avoiding Git Merge Conflicts with Deterministic Write Areas"

Nice write-up, Oliver. The "sparse index with delayed writers" framing really clicked for me. It also explains why the headings work so well mechanically: Git's three-way merge conflicts on overlapping or even adjacent changes, and each heading guarantees at least one untouched line between write points.

One question: within a section, are new entries sorted, or inserted directly under the heading? With the latter, any two same-letter additions would still collide. That matters because first letters aren't evenly spread, especially for software topics (api, auth, cache, ci, config...), so C and S will probably run hot.

Also, since agents love to "tidy" files (removing empty headings, re-sorting, turning lists into tables), a small CI check that all 36 headings exist and each entry sits under the right one might be what keeps the convention alive long term.

Would love to see numbers on this at some point. git merge-tree --write-tree makes it pretty easy to simulate append vs. sorted vs. sectioned.

Great points.

Yes, entries are sorted by filename within each section. So two additions under the same letter can still collide if they land in the same gap - especially while that section is sparse. As it fills up, the existing entries themselves create more natural merge anchors. So the 36 headings don't eliminate conflicts, they mainly remove the worst case where every new entry competes for the same append position.

And funny enough, the “agents will tidy this away” problem is already covered too. The current spec + keep-the-why-lint check that all 36 headings exist, entries are under the correct heading, and entries are sorted (E205, E206, E204). I learned pretty quickly not to rely on an agent politely respecting formatting conventions. :)

I really like the git merge-tree --write-tree idea. A comparison of append vs. globally sorted vs. sectioned would be worth measuring - ideally also with a deliberately skewed filename distribution rather than uniform random data.

That might become a follow-up to the article. Thanks!

Search Hashnode