git plugin: cherry-pick and revert have three claimants #112
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Defame1297/holocron#112
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Surfaced by two independent audits during the #99 ADR-0020 retrofit, wave 2. Pre-existing — not introduced by the retrofit. Both skills carried the overlap before wave 2 touched them, so it was deliberately held out of that wave's scope rather than resolved arbitrarily mid-flight.
The conflict
Three skills disagree about who owns
git cherry-pickandgit revert:git-branchesgit-history'sreferences/merging.md:8-9git-commitsreferences/cherry-pick.mdwith its own dispatch rowgit-historyREADME.mdjustifies carrying them viagit-branches' delegationA router acting on descriptions alone will land "cherry-pick abc123 onto release" in
git-commits, whilegit-branchesdocuments that it should go togit-history, which also implements it. Two skills carry near-duplicate procedure for the same operation.The rebase half is already resolved
Wave 2 fixed the rebase portion of the same tangle:
git-brancheswas routing rebase togit-history, which carries no rebase content and disclaims it in its own README. Rebase isgit-commits', which implements it inreferences/rewrite-history.md. That correction landed across four sites in0fde892.Cherry-pick and revert were left alone precisely because, unlike rebase, both claimants have a real case.
The two coherent resolutions
(a) They belong to
git-commits. Cleanest first principle —git-historyfinds,git-commitswrites, and cherry-pick and revert both write commits. Cost:git-history's Step 3 loses two of its three operations, and the "you located a commit, now act on it" flow breaks in half.(b) They belong to
git-history. Matchesgit-branches/references/merging.md, matchesgit-history's Step 3, matches its pre-retrofit README justification. Onlygit-commitsdissents. Cost: deletegit-commits/references/cherry-pick.mdand its dispatch row, and drop cherry-pick from its description.Whichever wins, the losing skill must drop the capability from its description too, not just its body — the description is the entire routing surface, and leaving a stale claim there means the router keeps picking the wrong skill regardless of what the bodies say.
Note on current state
git-history's description was corrected in wave 2 to stop disclaiming cherry-pick and revert (it read "not writing or rewriting commits", which deflected its own Step 3), and gained "backport" so cherry-pick is reachable by natural language at all. That change is correct under either resolution — it does not prejudge this issue.Related
#99 (the retrofit), #110, #111 (gate defects from the same wave).
Already resolved, closing without further changes. Verified against
main(post598a7c3/ #129): the ownership split isgit-commitsowns cherry-pick,git-historyowns revert — not the "one skill owns both" framing this issue's evidence table used.git-branches/references/merging.md:8: "Rebase and cherry-pick belong togit-commits; revert togit-history."git-history'sSKILL.mdStep 3: "cherry-pick isgit-commits'... Hand it the SHA; do not rungit cherry-pickfrom here."git revert <commit>is executed directly, no delegation.git-history'sREADME.md: "Cherry-pick is not this skill's:git-commitsowns it...git-branchesdelegates revert here."git-commits' description and dispatch row still claim cherry-pick; its only "revert" mentions are the Conventional Commits message type for SemVer classification, not a claim on thegit revertoperation.All three sites agree, and the description-level claim (the actual routing surface) is consistent with the body on all three.
598a7c3's own commit message confirms this was done deliberately during wave 3/4: "#112 (cherry-pick ownership, now resolved in favour ofgit-commits)" — just never closed out.