Re: [BUG] rebase -p loses commits

On Tue, May 17, 2011 at 12:07:38PM -0400, Andrew Wong wrote:

quoted

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