The branch patch checkout creates can never stamp a Patch: trailer, so revisions merge unrecorded #108

New issue

Open

opened 2026-08-15 12:54:47 +00:00 by a73x · 0 comments

a73x commented

2026-08-15 12:54:47 +00:00

(Migrated from git.a73x.sh)

[claude 2026-08-15] patch checkout <id> puts you on collab/<id>. The commit-msg hook stamps only when an open patch's recorded branch field equals the current branch (src/hooks.rs:307-325), and that field holds the branch the patch was created from — never collab/<id>. So the hook is silent by construction on the branch the tool itself just told you to use.

$ git-collab patch checkout 01ad09e5
Checked out patch 01ad09e5 (revision 1) on branch collab/01ad09e5; you were on main.
$ git-collab hooks status
commit-msg hook: installed (...)
HEAD is on 'collab/01ad09e5': no open patch records this branch, so nothing would be stamped
$ git commit -m "address feedback"      # no Patch: trailer
$ git checkout main && git merge --no-ff collab/01ad09e5 && git-collab sync
1 patch(es) look merged but are not recorded:
  01ad09e5  add feature
Record one with: git-collab patch merge <id>

The merge is detected but not recorded, and the --fixes issue stays open until someone runs patch merge by hand. On the original branch the same sequence stamps and sync records it automatically, so the automatic path works exactly until you use patch checkout to get the code back.

src/hooks.rs:298-304 already documents the general weakness — an ephemeral or renamed branch does not match, and silence is the right answer over guessing. This is narrower than that: collab/<id> is a name the tool generates itself, from the id it is trying to match. It is the one case where the branch name is not ambiguous provenance but a derivable fact, so silence is not forced here the way it is for a user's renamed branch.

Cheapest fix is probably for patch checkout to record the branch it creates (or for the hook to recognise the collab/<id> form and resolve the id directly), so that the revise → merge path records itself like the create → merge path does.

Found while verifying the git-collab skill's documented workflow; the skill now warns about it as a trap.

Migrated from git-collab issue b6839a7fbf56297c5cb71157671d63f5ae19d179.

Original author: a73x dev@a73x.sh.

[claude 2026-08-15] `patch checkout <id>` puts you on `collab/<id>`. The commit-msg hook stamps only when an open patch's recorded `branch` field equals the current branch (src/hooks.rs:307-325), and that field holds the branch the patch was *created* from — never `collab/<id>`. So the hook is silent by construction on the branch the tool itself just told you to use. ``` $ git-collab patch checkout 01ad09e5 Checked out patch 01ad09e5 (revision 1) on branch collab/01ad09e5; you were on main. $ git-collab hooks status commit-msg hook: installed (...) HEAD is on 'collab/01ad09e5': no open patch records this branch, so nothing would be stamped $ git commit -m "address feedback" # no Patch: trailer $ git checkout main && git merge --no-ff collab/01ad09e5 && git-collab sync 1 patch(es) look merged but are not recorded: 01ad09e5 add feature Record one with: git-collab patch merge <id> ``` The merge is detected but not recorded, and the `--fixes` issue stays open until someone runs `patch merge` by hand. On the original branch the same sequence stamps and `sync` records it automatically, so the automatic path works exactly until you use `patch checkout` to get the code back. src/hooks.rs:298-304 already documents the general weakness — an ephemeral or renamed branch does not match, and silence is the right answer over guessing. This is narrower than that: `collab/<id>` is a name the tool generates itself, from the id it is trying to match. It is the one case where the branch name is not ambiguous provenance but a derivable fact, so silence is not forced here the way it is for a user's renamed branch. Cheapest fix is probably for `patch checkout` to record the branch it creates (or for the hook to recognise the `collab/<id>` form and resolve the id directly), so that the revise → merge path records itself like the create → merge path does. Found while verifying the git-collab skill's documented workflow; the skill now warns about it as a trap. --- Migrated from git-collab issue `b6839a7fbf56297c5cb71157671d63f5ae19d179`. Original author: a73x <dev@a73x.sh>.