git rebase / history rewrite [LWN.net]

git rebase / history rewrite

Posted Feb 12, 2026 8:51 UTC (Thu) by kleptog (subscriber, #1183)
In reply to: git rebase / history rewrite by marcH
Parent article: Evolving Git for the next decade

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