From: Stephen Haberman <stephen@exigencecorp.com>
Date: Sat, 18 Jun 2011 17:12:22 GMT
Subject: Re: [PATCH] rebase -i -p: doesn't pick certain merge commits that are children of "upstream"
Message-ID: <20110618121222.03ee0b79@sh9>
In-Reply-To: <4DFCD6A5.7000707@sohovfx.com>


> 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