Git-absorb: Git commit –fixup, but automatic

What git-absorb does & how it works

• Tool for creating fixup! commits automatically from staged changes.
• It looks at modified lines, finds the commit that last changed those lines, and creates fixup commits targeting those commits.
• By default it only creates fixup commits; rebasing with --autosquash is a separate step, unless explicitly requested.
• If a hunk can’t be matched confidently, it leaves it staged and reports that, so you can handle it manually.

Workflow benefits described

• Popular for: fixing CI/lint errors across multiple commits; addressing review feedback that touches several older commits; cleaning up stacks of small “logical” commits before merge.
• Lets people keep granular, “story-like” commit history while still iterating messily, then regularize with absorb + autosquash.
• Often combined with magit, lazygit, git add -p, stacked branches, and tools like git machete or git-branchless.

Alternatives & comparisons

• Several people already use aliases or scripts: git commit --fixup with fzf, shell helpers targeting the last commit touching a file, or direct git commit --amend.
• Other auto-fixup tools mentioned: git-autofixup, git-fixup, Sapling/Mercurial equivalents (hg absorb), and lazygit’s stricter interactive base-commit finder.
• Some report git-autofixup’s hunk-based algorithm as more reliable or faster; others found git-absorb plenty accurate and “snappy.”

Enthusiasm vs skepticism

• Enthusiasts:
  • Say it “just does the right thing” most of the time, drastically cutting tedium in multi-commit PRs and stacked diffs.
  • Claim false positives are rare; worst case you fall back to manual fixups.
• Skeptics:
  • Prefer explicit control and worry about “magic” silently mis-assigning changes.
  • Some tried it and saw enough wrong targets that undoing the damage outweighed the benefits.
  • Many argue that good habits, git rebase -i, and squash merges make this unnecessary.

Broader debate: commit hygiene & squash merges

• One camp values carefully curated, atomic commits for better git blame, git bisect, revert/cherry-pick, and learning a codebase.
• Another camp squash-merges all PRs and treats per-commit cleanliness as largely wasted effort; the PR itself is the atomic unit.
• Stacked PRs/diffs and “review by commit” versus “review by PR” are heavily debated; GitHub’s limitations are cited on both sides.

Open / unclear points

• How often absorb mis-assigns changes in practice is disputed and clearly workload-dependent.
• No consensus on whether every individual commit should be buildable/CI-tested; trade-off between history purity and productivity is unresolved.