Re: [BUG] rebase -p loses commits
- From
Jeff King <peff@peff.net>
- Date
- May 17, 2011, 16:12 UTC
- Message-ID
- <20110517161234.GA21388@sigill.intra.peff.net>
- In-Reply-To
- <4DD29D4A.8090703@sohovfx.com>
On Tue, May 17, 2011 at 12:07:38PM -0400, Andrew Wong wrote:
Show 7 quoted lines
> > 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.
Show 5 quoted lines
> 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