Re: [BUG] rebase -p loses commits

[Jeff King <peff@peff.net>]

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