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

[Andrew Wong <andrew.w@sohovfx.com>]

On 11-06-18 11:17 AM, Stephen Haberman wrote:
> Letting C1 into the todo would mean having to explain to the user why
> some of their reorderings worked and others didn't.
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".  
Also, if we do a "rebase-i-p A1", the C1 branch will appear in the todo 
list.  A while ago I actually ran into this scenario, and I want to 
squash a commit onto the C1 branch, which I can't if I simply choose B1 
as the base.  To workaround it, I just made A1 the base so that the C1 
branch will appear in the todo for me to squash upon.  Otherwise, doing 
the squash onto C1 manually would've involved several more steps.
> I think that Jeff's use case of rebase-i-p'ing C1, which is not on the
> first-parent list of commits, should be an error as it delves into
> territory (topo reordering) that rebase-i-p can't fully handle.
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.