Repository navigation
Add git stack absorb and stack_absorb - #37
Merged
Merged
Conversation
DomBlack
added this pull request to stack #38
October 15, 2026 12:10
Fixing a review comment on the third PR down currently means git down twice, git modify -p, git top, and getting the hunk selection right by hand each time. absorb does the placing: stage the fixes, and each run of changed lines goes into the commit in this stack that last changed those lines, with everything above rewritten and restacked. On a terminal it shows the plan (file and lines, the commit and branch each hunk goes to, what it couldn't place and why) and asks before rewriting anything; --dry-run just shows the plan, --force skips the question, and -a / -u / -p stage first the same as create and modify. The result names each rewritten branch with its old tip, so a wrong guess can be put back with git branch -f and a restack, and anything left in the index is said so at the end rather than silently. git absorb and git ab are installed as aliases like the other commands.
An agent fixing a review comment on a PR lower in the stack shouldn't have to navigate down, amend and come back up any more than a person should, so the absorb use case gets a tool. It takes the same staging choice as the others and dry_run for the plan; the result carries the plan either way, i.e. where every hunk went and what stayed staged and why, and when the restack above the rewritten commits hits a conflict the result comes back alongside the conflict error so the agent can see the rewrite happened. The server instructions, the installed skill and the MCP docs describe it.
The README gets a section for git stack absorb alongside the other commands, with the two things worth knowing before you trust it: a change to lines no commit in the stack touched stays staged (as does a new or deleted file), and one run of changed lines that spans lines two commits changed goes into the newer one rather than being split. It also says how to put a branch back if it guessed wrong, since the old tips are printed. The architecture notes get the why: hunks are placed by line geometry over zero context diffs, each rewritten commit's tree is patched through git apply in a temporary index so git checks the removed lines before anything moves, every affected branch moves in one update-ref transaction (the current one included, which is what keeps the index and working tree alone), and the restack above is modify's.
The README and the help said to put the lowest rewritten branch back with git branch -f and restack. That loses the fix, since restack replays the current branch's rewritten commits (which no longer carry the hunk) onto the old tip, and git refuses branch -f on the checked out branch anyway. The recipe that works is git reset --soft to the current branch's old tip (the hunks come back staged), git branch -f for each lower branch, then git stack restack. Also: the MCP docs say the merge commit refusal names the branch, as the code does; next steps that say git stack restack are rewritten to stack_restack for agents; and the skill says stack_continue is what follows a stack_absorb conflict.
The notices loop that was printed in two places is one helper, the plural helpers live together, the command's branching (dry run, nothing to absorb, an applied absorb) has a test, and stack_absorb's test covers the result coming back alongside a conflict and checks b's tip moved. The skill's conflict rule reads as one sentence, its CLI line is wrapped, and the two long README lines are too.
DomBlack
force-pushed
the
absorb-command
branch
from
October 15, 2026 12:21
c1a619a to
d636340
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Last of the three absorb PRs: the command, the MCP tool and the docs. Fixing a review comment on the third PR down currently means git down twice, git modify -p, git top, and getting the hunk selection right by hand; with this it's stage the fixes and run git absorb (also git ab), and each run of changed lines goes into the commit that last changed those lines, with everything above rewritten and restacked.
On a terminal it prints the plan first (file and lines, the commit and branch each hunk goes to, what it couldn't place and why) and asks before rewriting anything. --dry-run just shows the plan, --force skips the question, and -a / -u / -p stage first the same as create and modify (they stage even with --dry-run, since that's what you asked for; the dry run only protects the commits). The result names each rewritten branch with its old tip and says what's still staged rather than going quiet about it.
stack_absorb is the same use case for agents, with staging and dry_run; the result carries the plan either way, and when the restack above hits a conflict the result comes back alongside the conflict error so the agent can see the rewrite happened. The README gets a section with the two things worth knowing (lines no commit in the stack touched stay staged, and a run spanning two commits' lines goes to the newer one), plus the undo recipe, which is reset --soft to the current branch's old tip so the hunks come back staged, branch -f for the lower branches, then a restack. I'd originally written branch -f on the lowest branch plus a restack, which actually loses the fix, so don't do that.
The aliases are installed by git stack install like the others, so an existing install picks them up on its next run.