> > That's beside the point though, as I firmly believe git should be more
quoted text
> > helpful in this situation. If "git rebase -i -p" doesn't help you fix
> > the problems, I'll see what I can do to help.
> 
> That's very cool, thanks. I'll start writing a test now.

I've attached a test. You were both correct, `git rebase -i -p` keeps
the merge intact and doesn't duplicate the commits. This is awesome.

So, I'm wondering what the best way to integrate this into our workflow
is. Ideally, I think it would be great to just do:

    git pull --rebase --preserve-merges

Or even better just `git pull` with branch.x.rebase=true and
branch.x.preserve-merges=true property (throw in a
branch.autosetuppreservemerges and I'll be set, haha).

While `git fetch + git rebase -i -p` will work every time, it won't be
fun to have the editor pop open, just exit it because we're not really
doing an interactive rebase, we're just borrowing its more powerful
rebase implementation, and repeat this each time a dev wants to do a
pull. Or, tell them to do a "git pull --rebase" most of the time, until
it screws up, then back up and do the other. Both doable, but not ideal.

I understand Johannes's scenario of rebasing the entire branch, and it
looks like rebase--interactive already supports this as well--e.g. if
you pass `-p`, you get our desired behavior, and if you don't pass `-p`,
you get Johannes's desired behavior of merge squashing.

Given rebase--interactive seems to be a superset of the current rebase
implementation, could the current rebase implementation just go away and
instead become a non-interactive caller (e.g. just avoid popping up the
editor with the pick list) of rebase--interactive's more powerful
rebase logic?

(Disclaimer: I'm throwing the term "more powerful" around without really
knowing whether that is true or not--for our scenario, it seems that
way, but there could be other cases I don't know about where the current
rebase implementation is superior to rebase--interactive's.)

Thanks,
Stephen