On 05/17/2011 01:44 AM, Jeff King wrote:
> Is it really the first-parentness here that is important to the
> asymmetry? I thought it was more the fact that "feature" has the merge,
> but "master" does not.
To know the fact that "feature" has the merge, don't we need to know
that "feature" is the first parent of the merge? For example, if "F" is
the head of "feature" and we're on "*" as a detached head, then we can
only say "feature" has the merge if we know "feature" is the first parent.
> So the outcomes are the same, but the reasoning is different. And isn't
> that what happens with Junio's patch (I tried a simple test and it
> seemed to be)?
I agree that the outcome of both should be the same. Junio's patch will
fix the case when we do "git rebase -p", but the bug will still appear
as soon as we do "git rebase -p -i", which I think is where the source
of the problem is. So we should be looking to fix the issue with "git
rebase -p -i", which will also fix "git rebase -p" too.
I think it's pretty reasonable for "rebase -p -i" to pick the merge
commit, which is already happening with "git rebase -p F". A possible
use case for picking the merge commit is to do a fixup/squash/reword on
"G" in the following graph:
F---G---H
/ /
B---M
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html