Re: [BUG] rebase -p loses commits

From: Jeff King <peff@peff.net>
Date: May 17, 2011, 05:39 UTC
Message-ID: <20110517053934.GB10048@sigill.intra.peff.net>
In-Reply-To: <7vfwoel6vw.fsf@alter.siamese.dyndns.org>

On Mon, May 16, 2011 at 01:36:51PM -0700, Junio C Hamano wrote:

Show 17 quoted lines

> Hmm, I am confused.  You have this:
> 
>    F---*  feature
>   /   /
>  B---M    master
> 
> and you are at "*".  If it were to rebase to linearize,
> 
>     B---M---F' 
> 
> with F' that has the same the contents as '*', possibly autoresolved by
> "am -3" and/or "rerere", should be what you would get.
> 
> But what does it mean to rebase that on top of master, preserving merges
> in the first place? You are already on top of 'master' and '*' itself
> should be what you should get, no?  IOW, shouldn't you already be
> up-to-date?

To be honest, I am not sure what should happen. How this example came about was that somebody had the same graph, except that a third branch, "origin", also pointed at "B". They were confused why "git rebase --pull" made them re-resolve the same conflict that they had already handled during the merge.

The answer, of course, is that rebase is linearizing the commits instead of trying to preserve the shape of history, and that they really wanted "rebase -p".

I constructed the simplified example to show that the issue didn't have to do with origin, but rather with linearizing.

So it's not a real-world example, in that sense. If it had done one of:

  1. Said "you are up to date" and one nothing.

  2. Put F' on top of M.

  3. Bailed and said "what you're doing is silly".

I would probably have shrugged and left it alone. But claiming success and losing F entirely is pretty bad.

> I don't use preserve-merge rebase either, but at least when you are
> strictly ahead of the target, nothing should happen, I think.
> 
> Perhaps this should be a good start?

Aside from how unreadable that shell conditional is getting, I think it's an improvement.

-Peff