Re: [PATCH] rebase -i -p: doesn't pick certain merge commits that are children of "upstream"
- From
- Andrew Wong <andrew.w@sohovfx.com>
- Date
- Jun 13, 2011, 17:30 UTC
- Message-ID
- <4DF64932.1090607@sohovfx.com>
- In-Reply-To
- <7vmxhlpvob.fsf@alter.siamese.dyndns.org>
On 06/13/2011 12:01 PM, Junio C Hamano wrote:
> There is no title to this test? >
Ah, that's embarrassing. I'll fix that. Thanks!
Show 6 quoted lines
> In general I think it is wrong to change behaviour depending on which > parent of a merge we are looking at (unless of course the user tells us > to, like "git log --first-parent"), so in that sense philosophically I > think the patch is going in the right direction, but I do worry about > potential regressions. >
I totally agree. Ever since Jeff brought up this issue, I've been wondering what issue/workflow is that patch trying to fix. If the "todo" list doesn't change the parent of the merge commits, git should be able to do a fast-forward on the merge, which means the merge won't be rewritten anyway. Just a wild guess: maybe back then, git will actually rewrite the merge regardless? Anyway, let's wait for a reply from Stephen.