Re: [PATCH] rebase -i -p: doesn't pick certain merge commits that are children of "upstream"
- From
Stephen Haberman <stephen@exigencecorp.com>
- Date
- Jun 18, 2011, 17:12 UTC
- 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.
Show 7 quoted lines
> 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