HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
tummychow
git-absorb
Rust2018–2026
tummychow / git-absorb

git-absorb

git commit --fixup, but automatic

45Distinct people
47Mentions
0Explicit recommenders
5.8KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

git commit --fixup, but automatic

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year47 dated mentions

Observed mentions: 2018-11-06 10:58:11 UTC to 2026-07-26 21:54:59 UTC.

02468102018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20182019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 4 mentions; 2 submissions, 2 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 2 mentions; 2 submissions, 0 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 6 mentions; 3 submissions, 3 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 8 mentions; 1 submissions, 7 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 6 mentions; 2 submissions, 4 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 10 mentions; 2 submissions, 8 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC101
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC422
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC220
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC312
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC633
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC817
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC624
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC707
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC1028

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
git absorb This is a port of Facebook's hg absorb, which I first read about on mozilla.dev.version-control: Facebook demoed hg absorb which is probably the coolest workflow enhancement I've seen to version control in years. Essentially, when your working directory has uncommitted changes on top of draft changesets, you can run hg absorb and the uncommitted modifications are automagically folded ("absorbed") into the appropriate draft ancestor changesets. This is essentially doing hg histedit + "roll" actions without having to make a commit or manually make history modification rules. The command essentially looks at the lines that were modified, finds a changeset modifying those lines, and amends that changeset to include your uncommitted changes. If the changes can't be made without conflicts, they remain uncommitted. This workflow is insanely useful for things like applying review feedback. You just make file changes, run hg absorb and the mapping of changes to commits sorts itself out. It is magical. Elevator Pitch You have a feature branch with a few commits. Your teammate reviewed the branch and pointed out a few bugs. You have fixes for the bugs, but you don't want to shove them all into an opaque commit that says fixes, because you believe in atomic commits. Instead of manually finding commit SHAs for git commit --fixup, or running a manual interactive rebase, do this: git add $FILES_YOU_FIXED git absorb --and-rebase git absorb will automatically identify which commits are safe to modify, and which staged changes belong to each of those commits. It will then write fixup! commits for each of those changes. With the --and-rebase flag, these fixup commits will be automatically integrated into the corresponding ones. Alternatively, you can check its output manually if you don't trust it, and then fold the fixups into your feature branch with git's built-in autosquash functionality: git add $FILES_YOU_FIXED git absorb git log # check the auto-generated fixup commits git rebase -i --autosquash master Installing The easiest way to install git absorb is to download an artifact from the latest tagged release. Artifacts are available for Windows, MacOS, and Linux (built on Ubuntu with statically linked libgit2). If you need a commit that hasn't been released yet, check the latest CI artifact or file an issue. Alternatively, git absorb is available in the following system package managers: Repository Command Arch Linux pacman -S git-absorb Debian apt install git-absorb DPorts pkg install git-absorb Fedora dnf install git-absorb Flox flox install git-absorb FreeBSD Ports pkg install git-absorb Homebrew and Linuxbrew brew install git-absorb MacPorts sudo port install git-absorb nixpkgs stable and unstable nix-env -iA nixpkgs.git-absorb openSUSE zypper install git-absorb Ubuntu apt install git-absorb Void Linux xbps-install -S git-absorb GNU Guix guix install git-absorb Windows Package Manager winget install tummychow.git-absorb Compiling from Source You will need the following: cargo Then cargo install git-absorb. Make sure that $CARGO_HOME/bin is on your $PATH so that git can find the command. ($CARGO_HOME defaults to ~/.cargo.) Note that git absorb does not use the system libgit2. This means you do not need to have libgit2 installed to build or run it. However, this does mean you have to be able to build libgit2. (Due to recent changes in the git2 crate, CMake is no longer needed to build it.) Note: cargo install does not currently know how to install manpages (cargo#2729), so if you use cargo for installation then git absorb --help will not work. There are two manual workarounds, assuming your system has a ~/.local/share/man/man1 directory that man --path knows about: build the man page from source and copy This requires that the a2x tool be installed on your system. cd ./Documentation make mv git-absorb.1 ~/.local/share/man/man1 download a recently-built man page find a recent build as in Installing above download the git-absorb.1 file and unzip move it to ~/.local/share/man/man1 Usage git add any changes that you want to absorb. By design, git absorb will only consider content in the git index (staging area). git absorb. This will create a sequence of commits on HEAD. Each commit will have a fixup! message indicating the message (if unique) or SHA of the commit it should be squashed into. If you are satisfied with the output, git rebase -i --autosquash to squash the fixup! commits into their predecessors. You can set the GIT_SEQUENCE_EDITOR environment variable if you don't need to edit the rebase TODO file. If you are not satisfied (or if something bad happened), git reset --soft PRE_ABSORB_HEAD will reset to the pre-absorption commit and recover your old state. (You can also find the commit in question with git reflog.) And if you think git absorb is at fault, please file an issue. How it works (roughly) git absorb works by checking if two patches P1 and P2 commute, that is, if applying P1 before P2 gives the same result as applying P2 before P1. git absorb considers a range of commits ending at HEAD. The first commit can be specified explicitly with --base <ref>. By default the last 10 commits will be considered (see STACK SIZE in git-absorb.adoc for how to change this). For each hunk in the index, git absorb will check if that hunk commutes with the last commit, then the one before that, etc. When it finds a commit that does not commute with the hunk, it infers that this is the right parent commit for this change, and the hunk is turned into a fixup commit. If the hunk commutes with all commits in the range, it means we have not found a suitable parent commit for this change; a warning is displayed, and this hunk remains uncommitted in the index. Documentation For additional information about git-absorb, including all arguments and configuration options, see Documentation/git-absorb.adoc, or the git-absorb manual page. TODO
Read the full README on GitHub

What Hacker News says

47 sources
I am writing far less code than I used to and I’m finding that reviewing is a different skill entirely (and one I need some work on). I have always worked by myself and my past reviews were the sleep on it and see how it reads in the morning variety. I liked the article because what I struggle a little bit with is where to start (even though I wrote the ticket before I pointed the agent at it and often stay in the sessions to supervise and direct). There’s something that just feels bewildering about code I didn’t write. One thing reviewing does make me more disciplined about is making the agent write small diffs and descriptive commit check points. Probably the default for many of you who work on teams, but something I didn’t really follow when I had the entire code context and changes in my head. I have been making use of git-absorb. Lea
Read the rest
ving a really tidy git history is satisfying. https://github.com/tummychow/git-absorb
In Reviewing code you didn't write
I've worked with git using the mega-merge approach, and one thing I found is that git-absorb won't merge commits into anything that precedes a merge. It works fine for absorbing changes into earlier commits on a feature branch, but not from the WIP branch back into the multiple feature branches that are the parents of the mega-merge. jj handles this with no problems. From this comment on the git-absorb issue tracker I wouldn't expect it to be fixed soon either: https://github.com/tummychow/git-absorb/issues/134#issuecomm...
In Jujutsu megamerges for fun and profit
>The absorb command will do a lot of this for you by identifying which downstream mutable commit each line or hunk of your current commit belong in and automatically squashing them down for you. This feels like magic every time I use it (and not the evil black box black magic kind of magic where nothing can be understood), and it’s one of the core pieces of Jujutsu’s functionality that make the megamerge workflow so seamless. IUUC This is already implemented for git as an extension. https://github.com/tummychow/git-absorb I think this is such a basic thing that should be part of any DVCS implementation.
In Jujutsu megamerges for fun and profit
I've been doing stacked PRs for ~2 years now. Thus, I don't quite see the need for this CLI. Git has had some additions in the last few years that make this work natively – specifically the --update-refs flag[1] or the rebase.updateRefs config. Combined with `git commit --fixup`, rebase.autoStash, and rebase.autoSquash rebasing stacks becomes a breeze (as long as you work off from the tip of your stack). Add in git-absorb[2] and the heavy-lifting is taken care of. My biggest gripe with GitHub when working with stacks – and something that's not clarified in these docs – is whether fast-forward merges are possible. Its "Merge with rebase" button always rewrites the commit. They do mention that the stack needs to be rebased in order to merge it. My workaround has been `git merge --ff-only top-branch-of-stack` to merge the entire stack locall
Read the rest
y into main (or anything in between actually) and then push. GitHub neatly recognizes that each PR in the stack is now in main and marks them all as merged. If there are subsequent PRs that weren't merged it updates the base branch. Having said that, it's great to see GitHub getting a proper UI for this. It's also great that it understands the intent that branch B that goes on top of branch A is a stack and thus CI runs against. I just hope that it's not mandatory to use their CLI in order to create stacks. They do cover this briefly in the FAQ[3], but it might be necessary to use `gh stack init --adopt branch-a branch-b branch-c`. On the other hand, if that removes the need to manually create the N PRs for my stack, that's nice. [1]: https://git-scm.com/docs/git-rebase#Documentation/git-rebase... [2]: https://github.com/tummychow/git-absorb [3]: https://github.github.com/gh-stack/faq/#will-this-work-with-...
In GitHub Stacked PRs
git rebase conflict resolution is a lot less scary with the zdiff3 merge.conflictStyle option. Also incremental rebasing with mergify/git-imerge/git-mergify-rebase/etc is really helpful for long-lived branches that aren't merged upstream. https://github.com/brooksdavis/mergify https://github.com/mhagger/git-imerge https://github.com/CTSRD-CHERI/git-mergify-rebase https://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee650... I also love git-absorb for automatic fixups of a commit stack. https://github.com/tummychow/git-absorb
In Git Rebase for the Terrified

Showing the 15 most recent of 47 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.