git rebase / history rewrite [LWN.net]

git rebase / history rewrite

Posted Feb 14, 2026 0:38 UTC (Sat) by marcH (subscriber, #57642)
In reply to: git rebase / history rewrite by marcH
Parent article: Evolving Git for the next decade

> Rewriting history relies on (at least) two key concepts...

... and a third, very important one is this:

> "so if you added a commit, all children are rebased automatically". Conflicts are data, not emergencies. "You can commit them and resolve them at any later point in time."

With git, you have to choose between merges or rewrites. With jj, you can combine both all the time:

https://v5.chriskrycho.com/journal/jujutsu-megamerges-and...

The first time one does something useful with "jj absorb" is a point of no return. No one in their sane mind would ever use git again to achieve the same thing. It would feel like coding in assembly.

to post comments

git rebase / history rewrite

Posted Feb 16, 2026 10:10 UTC (Mon) by taladar (subscriber, #68407) [Link] (2 responses)

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.

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.