git rebase / history rewrite [LWN.net]

git rebase / history rewrite

Posted Feb 12, 2026 7:55 UTC (Thu) by marcH (subscriber, #57642)
Parent article: Evolving Git for the next decade

> There are a number of things that Jujutsu got right, he said. For example, history is malleable by default. "It's almost as if you were permanently in an interactive rebase mode, but without all the confusing parts." [...] These features are nice to have, he said, and fundamentally change how users think about commits. "You stop treating them as precious artifacts and rather start treating them as drafts that you can freely edit".

Rewriting history relies on (at least) two key concepts 1. Change-Ids (as in Gerrit and others) and 2. The distinction between mutable ("rebasable", yuck) versus immutable commits.

Funny enough, most GitHub projects don't care much "clean" git histories and do not need these concepts:
https://blog.buenzli.dev/announcing-development-on-flirt/...
https://zachholman.com/posts/git-commit-history/ "Utter Disregard for Git Commit History"

So these key concepts are needed only by "traditional" git users like for instance kernel developers who... spent years ignoring and/or dismissing them?!? https://lwn.net/Articles/1037069/ "A policy for Link: tags"

Very strange.

Other relevant references:
https://fossil-scm.org/home/doc/tip/www/rebaseharm.md
https://gitlab.com/gitlab-org/gitlab/-/issues/24096

to post comments

git rebase / history rewrite

Posted Feb 12, 2026 8:51 UTC (Thu) by kleptog (subscriber, #1183) [Link] (2 responses)

I see Jujitsu has the concept of "Change-Id" as a first-class feature, and that it can manage it so it lines up with Gerrit's Change-Id for a seamless experience. No more configuring the commit-hook for example. Very nice! Definitely putting jj on the list of things to try.

Unfortunately, standard Git will strip the header out during cherry-pick/rebase, and it doesn't survive format-patch/apply-mail. But if Jujitsu can catch on, perhaps we will finally have a global unique patch identifier that can work cross repo.

BTW, I also lament the lack of attention for clean commit histories. It's the main reason we use Gerrit rather than something like GitLab.

git rebase / history rewrite

Posted Feb 12, 2026 15:11 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

FWIW, we use GitLab and do care about clean histories. GitLab is nowhere near as hostile to rebase workflows as Github.

git rebase / history rewrite

Posted Feb 12, 2026 15:12 UTC (Thu) by marcH (subscriber, #57642) [Link]

> Definitely putting jj on the list of things to try.

Warning: there is no way back :-)

You know something is worth learning when the problem is not finding a good, free tutorial but _choosing_ which one to pick!

> But if Jujitsu can catch on, perhaps we will finally have a global unique patch identifier that can work cross repo.

In June 2025 there was a very discussion on the git mailing-list about adding Change-Ids to git:
https://lore.kernel.org/git/CAESOdVAspxUJKGAA58i0tvks4ZOf...

There may have been other ones but this one definitely stands out.

> BTW, I also lament the lack of attention for clean commit histories. It's the main reason we use Gerrit rather than something like GitLab.

Bisectable histories[*] will never go away but yeah, they seem to be less and less "mainstream" :-(

Note appearances can be deceiving. As a coincidence, I was bisecting some really weird regression in cpython yesterday and it worked thanks to a "clean" history despite contributors apparently _not_ force-pushing to Github during review. That's because maintainers seem to always squash before merge, which Github supports just fine. You lose the ability to review more than one final commit per PR but for some GH projects that loss may be an acceptable price to pay.

Technically, nothing would stop GH projects from alternating between the force-push review model and not depending on the PR at hand but that would surely confuse the hell out of most people - many of them don't even realize that two different usage models exist in the first place!

[*] on second thought, "bisectable" is less subjective than "clean" and still generic enough.

git rebase / history rewrite

Posted Feb 14, 2026 0:38 UTC (Sat) by marcH (subscriber, #57642) [Link] (3 responses)

> 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.

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.