zlacker

>>flexdi+(OP)
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.

>>the_gi+Rwe
Yeah, I do this too: The `--onto` solution feels a bit too magical at times and an interactive rebase is pretty clear about what's happening.

>>Xophme+p5f
Add `--update-refs` to your interactive rebase and it will give you an easy line to know how many commits to drop because it will add an `update-ref` line for the old branch. You can just easily delete everything up to and including that `update-ref` line and don't have to manually pull up a git log of the other branch to remember which commits already merged.

(Plus, of course, if you have multiple branches stacked, `--update-refs` makes it easier to update all of them if you start from the outermost branch.)

>>WorldM+SJf
Nice; thanks :) I usually squash-merge. Does that break this workflow?