Ah, I've been doing this for ages but apparently this practice has a name
Stacked Diffs with git rebase —onto
21–30 of 210 posts
Re: Stacked Diffs with git rebase —onto
#22Earlier quoted context omitted.
The main issue I kept having when trying to do this with just git is then managing all the branch names to be attached to the right moved commits, so that my stack could be reviewable on github's open PRs. Does jj help with that at all? I've experimented a bit with git-town.com (OSS) and now everyone at $DAYJOB uses graphite.com (SaaS) which does that part very well.
It’s one of the core features that rebases, including branch names (bookmarks in jj) work ‘correctly’. You can rebase whole dags, including merges, with multiple named heads with just one jj rebase -b.
note that bookmarks don't float, unlike git branches, so if your pattern is to produce a lot of commits, you'll want something to keep your jj bookmarks pointing to the top of your pile of commits.
this is less of a problem if you're more into the 1 change == 1 commit workflow.
Re: Stacked Diffs with git rebase —onto
#23Re: Stacked Diffs with git rebase —onto
#24Earlier quoted context omitted.
It’s one of the core features that rebases, including branch names (bookmarks in jj) work ‘correctly’. You can rebase whole dags, including merges, with multiple named heads with just one jj rebase -b.
note that bookmarks don't float, unlike git branches, so if your pattern is to produce a lot of commits, you'll want something to keep your jj bookmarks pointing to the top of your pile of commits. this is less of a problem if you're more into the 1 change == 1 commit workflow.
There's an experimental-advance-branches feature which helps with that!
Re: Stacked Diffs with git rebase —onto
#25Earlier quoted context omitted.
It’s one of the core features that rebases, including branch names (bookmarks in jj) work ‘correctly’. You can rebase whole dags, including merges, with multiple named heads with just one jj rebase -b.
note that bookmarks don't float, unlike git branches, so if your pattern is to produce a lot of commits, you'll want something to keep your jj bookmarks pointing to the top of your pile of commits. this is less of a problem if you're more into the 1 change == 1 commit workflow.
There's a very common alias `jj tug` for this case:
tug = ["bookmark", "move", "--from", "heads(::@- & bookmarks())", "--to", "@-"]
Re: Stacked Diffs with git rebase —onto
#26For the example given, would merging branch 2 into branch 1 then branch 1 into main achieve the same effect?
Perhaps not an option if you need to release the work in branch 1 before the work in branch 2 is ready/reviewed/etc.
Re: Stacked Diffs with git rebase —onto
#27That particular case can be solved much easier by rebasing outer-most branch with `--update-refs` flag.
I came into the comments specifically to ask if this flag existed. I feel bad that the author developed this whole flow just because they didn't know about this, but that's pretty common with git.
Re: Stacked Diffs with git rebase —onto
#28For the example given, would merging branch 2 into branch 1 then branch 1 into main achieve the same effect? Perhaps not an option if you need to release the work in branch 1 before the work in branch 2 is ready/reviewed/etc.
The point of this technique is to keep them separate. See the other comments about `--update-refs`.
Re: Stacked Diffs with git rebase —onto
#29Jujutsu comes in handy here for the same usecase: https://github.com/jj-vcs/jj https://www.stavros.io/posts/switch-to-jujutsu-already-a-tut... Also found https://github.com/gitbutlerapp/gitbutler
Half my team switched to JJ this year, and I do find stacking PRs to be much more pleasant now. We had previously tried out Graphite but it didn't really stick.
I wrote up a little way to use JJ's revsets to make it easy to push an entire stack of branches in one command:
https://crabmusket.net/2025/jj-bough-a-useful-alias-for-stac...
Re: Stacked Diffs with git rebase —onto
#30Even if `--update-refs` didn't exist, my experience is that git can identify duplicate commits produced by rebase, and knows to skip them when rebasing the same commits to the same place again. Am I imagining that?