stack-absorb

Stack Absorb

Distribute a set of changes across the correct commits in a Graphite stack, by hand, when gt absorb's blame-based algorithm won't produce a clean result. This is slower than gt absorb -f but gives a coherent, reviewable history: each target branch gets exactly the hunks that belong to it, described in its own commit message, with nothing stray swept in.

When to reach for this vs. plain gt absorb

Check git status --short first. Untracked (??) files are never absorbed even with gt absorb -a - that flag only stages unstaged tracked changes, file creations are never picked up. If any untracked files are part of the intended change, treat them as part of the manual split below rather than expecting the dry-run to cover them.

Then try gt absorb -a --dry-run first - it's free and sometimes it's exactly right. Read its output critically:

• If every hunk absorbs into a commit that's a good semantic fit, there's no significant "Not absorbed" leftover, and no untracked files were left out of consideration, just run gt absorb -a -f (or let the user run it) and stop here.
• If it scatters hunks across commits that are a poor conceptual fit (a stale docs-sync commit, a commit about a different concern that happens to touch the same lines), or leaves substantial new code as "Not absorbed" (no prior line to blame onto - new functions, new JSX blocks, new state), that's the signal to do this manually. Tell the user what gt absorb --dry-run would do and why it's messier than a hand split, and confirm before proceeding (AskUserQuestion) - this is a judgment call about commit history shape, not a mechanical one.

Step 1: Map every change to its target branch

For each distinct concern in the diff, find the commit that should own it:

git log --oneline -S"<distinctive string from the change>" --all -- "<file>"

Pick a string that's specific to the concept being changed (a function name, a UI label, an error message), not boilerplate. The oldest/most relevant match is usually the commit that introduced what you're now modifying. Then resolve that commit to a current branch tip - git branch --contains alone is not the answer, only a candidate list: in a stacked history every branch above the true owner also contains that commit, since it's in their ancestry too.