git rebase / history rewrite [LWN.net]

git rebase / history rewrite

Posted Feb 16, 2026 10:10 UTC (Mon) by taladar (subscriber, #68407)
In reply to: git rebase / history rewrite by marcH
Parent article: Evolving Git for the next decade

The documentation from that article for jj absorb reads

> This command splits changes in the source revision and moves each change to the closest mutable ancestor where the corresponding lines were modified last. If the destination revision cannot be determined unambiguously, the change will be left in the source revision.

which seems heuristic and unreliable to be honest, in particular to keep related changes together in the same commit.

to post comments

git rebase / history rewrite

Posted Feb 16, 2026 13:30 UTC (Mon) by marcH (subscriber, #57642) [Link] (1 responses)

> which "seems" heuristic and unreliable

You also know a new tool is great when the people who like it are the ones actually using it, while the people who don't like it are the ones who haven't tried it :-)

- I don't know the exact "distance" but the changes have to be pretty close to older changes, otherwise jj absorb does not touch them. I found it pretty conservative in practice.
- This is not a command to use all the time, it's meant to be run on fixups. But it saves a tremendous amount of time in some specific phases, like for instance when addressing small review comments.
- Unlike git, jj has a very reliable "jj undo" command. Then you can switch to "jj squash [-i] ... filename" each file/diff/hunk individually in cases "jj absorb" did not do what you wanted. "jj squash" is still more convenient and faster than with git. Also, "jj undo" is not even needed when the distance was too big.

tl;dr: jj absorb is amazing.

Don't try jj if by some miracle you never experienced much frustration with git. But don't listen to the people who haven't tried it either; just ignore them.

git rebase / history rewrite

Posted Feb 17, 2026 9:49 UTC (Tue) by taladar (subscriber, #68407) [Link]

Can't say I have ever felt much frustration with git related to working on multiple branches merged together at the same time and having trouble associating fixups with their respective changes.

Never really got the UI frustrations people claim around git in general to be honest, are some of the parameters and sub commands a bit badly named, sure. But the overall workflow is solid and works on a simple data structure that I can easily wrap my head around.

I honestly wouldn't even know where to begin trying jj in such a way that it would show off something it can do better without completely revamping the way I think about source control to that extremely weird jj model of working on multiple branches at the same time in the same work tree.