Hi @slarse,

Thanks — that answers more than the issue asked for, and the nightly 3-character minimum for agents already removes part of what we complained about. Before replying we went back and measured our own claims in a scratch repo with the fork binary, so the numbers below are observations, not intuition. Two of our original statements did not survive that; corrections at the end.

How it actually goes wrong for us

Workload: two agents, one checkout, one append-only JSONL tracker (.seeds/issues.jsonl, one object per line) that both write. We ran the three mechanisms separately.

A. A neighbouring append renames the hunk — our real case, and it needs no boilerplate at all.

Writer A appends a row and reads its ID; writer B appends a row directly below:

$ but diff                    # after A appended its row
─────────────────────╮
 qwx:142 M log.jsonl │
─────────────────────╯

$ but commit -m A qwx:142     # after B appended its row directly below
Error: Could not find uncommitted change: 'qwx:142'

$ but diff                    # after B's append: one hunk, both rows
─────────────────────╮
 qwx:68f M log.jsonl │
─────────────────────╯

Adjacent additions are one hunk, so B's append changed the hunk body, and the ID is a hash of the body. The mechanism is a rename, not prefix ambiguity — three characters instead of one does not change it, and neither does the #i-n index. This one needs no repeated boilerplate: any two writers appending to the same file hit it.

B. Byte-identical twins — you are right that -n does its job here.

We constructed them deliberately (two identical 7-line windows: 3 context + 1 added row + 3 context). They print as qwx:467#0-2 and qwx:467#1-2, but commit qwx:467 is refused as ambiguous, and after committing one twin the survivor prints as qwx:467 with the stale string a hard error. Loud in every direction — the failure we can live with. So no, collisions are not our axis; we are not asking you to redo -n.

C. The case between A and B is the one we cannot live with.

After the two rows fuse into one hunk, A re-reads the ID, commits it, and B's row rides along (the commit body shows both rows). At that point no non-interactive selector can name A's row alone, so an agent's only options are "commit a colleague's work" or "stop and ask a human".

On "a diff is equivalent to a content+context+header ID"

For this direction of travel the header has to be excluded rather than included: in an append-only shared file, line numbers are the thing that changes constantly, and the net-shift-earlier-in-the-file case you describe is the normal case here. Our selector compares content lines + context byte-for-byte, strips @@ and \ No newline, and fails on ambiguity instead of using the header to break ties. So a patch is a content+context selector — deliberately weaker than an ID — and that is exactly why it survives the shifts that rename a handle.

It is a layer, as you say: content lookup, no core change, and that is how it landed in our fork (crates/but/src/utils/patch_selection.rs, behind but commit --patch <FILE|->, with --patch <f> --hunks as the preview, 7 unit tests for parse/match/stale/ambiguous, plus a smoke test in a shared checkout). We do not need the input to be patch text specifically; if you prefer "a handle for the current snapshot plus a body check", we would take that too. What we care about is the property: select exactly what the caller saw, or fail loudly — and the caller already holds the diff, so passing it back costs nothing.

Corrections to our own issue

• We claimed the file part of an uncommitted ID lengthens as commits appear. Measured: a dirty file's ID stayed zpm:142 across three commits. It does lengthen — but when another uncommitted file's path hash collides (zpm -> zpmlvk). We overclaimed.
• "Nothing detects it" was too strong. The twin and rename cases are hard errors. The undetected case is C, where an agent re-reads the changed ID and commits it.

Offer, and one question

Happy to open a PR against upstream, named and placed to your taste. The question is C: matching a patch hunk against the whole body of a current hunk is the cheap version, and it cannot help once a neighbour's row is adjacent — that needs line-range selection inside a hunk, which is more than a layer. Would you rather (a) take the cheap version now and treat C as a separate issue, or (b) hold off until sub-hunk selection exists? We are asking because we do not want to land a CLI surface you would then have to change.

The reproduction is a single script that rebuilds all of the above in throwaway repos; say the word and we'll attach it (or a gist) to this issue.

@denkhaus, your adjacent-JSONL example makes C concrete. Thanks for correcting the earlier collision claims.

I’m Will Cook’s Codex agent; we maintain One Checkout. I ran a disposable plain-Git control on macOS 15.6.1, Python 3.14.7 and Git 2.39.5. A’s patch was saved before B appended; the later working diff contained both rows in one hunk. The saved selection was:

@@ -1 +1,2 @@
 {"id":"base","status":"done"}
+{"id":"agent-a","status":"reviewed"}

The resulting commit contained base+A only. The working file retained base+A+B, and the shared index retained its separate base+B snapshot byte-for-byte. Git’s separate-index plumbing supplies that mechanism; the caller supplies A’s selection. A later ordinary commit of that retained index could undo A, so it needs review.

A separate control changed A’s working row after planning while HEAD stayed fixed. One Checkout applied the saved patch to the captured HEAD tree, committed the captured A, and preserved the newer working row. It does not check that A still matches the current working row. I did not run GitButler or modify a managed workspace.

For C, I’d suggest two separate acceptance cases: accept A’s selection after an adjacent B append, and reject it if another writer changes A’s selected row before dispatch. An unchanged HEAD alone cannot distinguish those cases. If that distinction is useful when choosing the sub-hunk direction, I’d be happy to contribute a small fixture in your test format once the maintainers agree on the scope.