Stacked Diffs with git rebase —onto
18 comments
·December 1, 2025dimitrieh
Jujutsu comes in handy here for the same usecase:
https://www.stavros.io/posts/switch-to-jujutsu-already-a-tut...
Also found https://github.com/gitbutlerapp/gitbutler
ndr
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.
baq
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.
sockbot
We use graphite at work to automate this workflow. The whole point is avoid this toil.
jbjbjbjb
I think ‘git rebase —-update-refs’ is the better way to go for this scenario
enbugger
Is there any good guide on how to solve the issue which OP solves?
the_gipsy
I usually just `git rebase origin/main -i` after the base branch has been merged there, and this means I need to explicitly drop the merged commits, but I can inspect what's happening.
motoboi
I believe the author would love stg: https://stacked-git.github.io/guides/tutorial/#patches
schacon
GitButler handles all of this pretty automatically, if you don't want to deal with the Git gymnastics needed here.
perspectivezoom
I'm a heavy user of git-spice: https://abhinav.github.io/git-spice (created by a former coworker) and can't really go back to a time without it. While still not nearly as good as Facebook's Phabricator, it's probably the best workflow for small, focused stacked PRs you can achieve in a Github / Gitlab based repository.
politelemon
This marker branch step feels like a workaround to a missing capability. It's something I can easily see one forgetting especially if they haven't been doing stacked diff workflows regularly.
sublinear
I agree it seems error prone. I'm not sure if I'm misunderstanding something, but I use `git cherry-pick` when I know I need to move commits around that might have conflicts. The problem with rebase can be that the user doesn't fully understand all the options being applied and end up with a "bad" merge.
I don't usually want to rewrite history. I just want the target branch with all my commits on top (I usually squash the feature branch into one commit anyway). I have yet to run into a situation where this isn't good enough.
If the branch diverges so much and has so many commits that this simpler approach doesn't work, that might not be a git problem, but a project management one. It's still always nice to know git has tools to get me out of a jam.
nrhrjrjrjtntbt
Fun stuff, but I'll stick to trunk based dev, small PRs... thanks!
taejavu
Stacking commits lets you do that without having to wait for each change to be reviewed/merged to the main branch before you iterate on top of those changes.
nrhrjrjrjtntbt
True. I find I rarely need it: standard rebase or merge do the trick. If they don't the review cycle or PR size may be too high. Super rare I need onto. So rare I look up how to do it when I do.
hahahacorn
I consider myself a shmedium experienced dev who likes to learn their tools and read source.
This seems like a house of cards whose juice isn’t worth the squeeze. But I would love to split up my PRs into smaller pieces.
I just would hate to waste time with an incomprehensibly goofed git history because I forgot a command.
That particular case can be solved much easier by rebasing outer-most branch with `--update-refs` flag.