On Tue, May 17, 2011 at 12:07:38PM -0400, Andrew Wong 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. No, if "F" is the head of "feature", then it does _not_ have the merge. But it's not the merge that is important, it is really the fact that if we are rebasing "feature" on "master", that "master ^feature" is empty. IOW, we are already a superset. In this example, though, the merge is the thing that gives us that superset. > 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. Ah, I see. Yes, in that case, we should definitely be fixing "git rebase -p -i". -Peff -- 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