Re: [PATCH] rebase -i -p: doesn't pick certain merge commits that are children of "upstream"

The bug section in rebase's documentation does mention that "attempts
to reorder commits tend to produce counterintuitive results", which I
think serves as a fairly good warning saying "reorder at your own
risk".

True.

Also, if we do a "rebase-i-p A1", the C1 branch will appear in
the todo list.

Hm, good point.

There shouldn't be any topo-reordering unless the user explicitly 
changes the order of the commit.  The user is faced with the same 
limitations (and bugs) as rebase-i-p'ing D1, so we shouldn't have to 
handle the C1 case any different.  rebase is perfectly capable of 
handling the D1 case, just as how the C1 case is handled.  We're only 
running into this issue because we're trying to filter out C1 when 
rebase-i-p'ing B1.

Okay, that makes sense.

I agree with you then, with the behavior of "rebase-i-p A1" plus the
disclaimer in the docs warrants C1 showing up, C1 should be in the
todo list for "rebase-i-p B1" as well.

...I can think of cases where personally I'd want to only move
around commits on the first-parent line, e.g. even in the case of
"rebase-i-p A1", to have less noise (C1 and any others on its branch)
in the todo, but at that point it sounds like I'm projecting behavior
onto rebase-i-p that isn't actually there.

- Stephen