Git-absorb: Git commit –fixup, but automatic

Original Article ↗ Hacker News Discussion ↗

Git-absorb, a tool that automatically turns staged changes into `fixup!` commits against the most likely original commits, is being evaluated as a way to streamline maintaining “clean” or atomic Git histories. Supporters say it removes tedious manual work when fixing CI issues, lint errors, or review feedback across many commits, especially in stacked-PR or non-squash workflows, and integrates well with tools like Magit and Lazygit. Skeptics question the value of automated guessing and highly curated histories when many teams squash-merge pull requests anyway, arguing that the benefits must be weighed against added complexity, CI costs, and the realities of typical review practices.

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.