Re: overly smart rebase - bug or feature?

From: Fedor Sergeev <fedor.sergeev@sun.com>
Date: Nov 10, 2008, 23:36 UTC
Message-ID: <20081110233649.GI6799@sun.com>
In-Reply-To: <7vod0n41i5.fsf@gitster.siamese.dyndns.org>

On Mon, Nov 10, 2008 at 03:14:42PM -0800, Junio C Hamano wrote:

Show 8 quoted lines

> Fedor Sergeev <Fedor.Sergeev@Sun.COM> writes:
> 
> > I have recently hit a behavior which might well be a feature, 
> > but it was very surprising (in a bad sense) to me.
> 
> It is a feature misfiring.
> 
> Rebase is essentially a repeated cherry-pick, and a cherry-pick of commit

But cherry-pick does fail, as shown in my original mail!

Show 6 quoted lines

> A on top of commit B is done by a simplified 3-way merge between A and B
> using the parent of A as the common ancestor.
> 
>      A                          A'
>     /                          /
>    A^... pseudo history ...---B

Well, my history is exactly that, not pseudo (and I dont quite follow your reasoning yet to understand whether this is important or not):

   A   B
    \ /
     A^

A^ *is* a common ancestor of both A and B.

> 
> When your history has renamed Makefile to Makefile2 (thereby losing
> Makefile)

My history did not rename Makefile. There were three identical Makefiles (in A^) After that one was deleted (in B). On alternative branch it was edited (in A).

If I do *merge* A into B then it fails. If I do *cherry-pick* A into B then it fails. If I do *rebase* A onto B then it succeeds.

Show 10 quoted lines

> while transition from A^ to A modified Makefile, the difference
> between A^ to A that is applied to B to produce A' contains only the
> change about Makefile (and does not talk about the unchangedness of
> Makefile1 nor Makefile2 --- in fact, when A' is created, the machinery
> does not even know if A^ and A had Makefile1 or Makefile2).
> 
> When applying the change to Makefile, it notices that B does not have
> Makefile, but there is a path that is _identical_ to the preimage your
> change applies to (namely, Makefile2).  To support people who rename
> Makefile to Makefile2 in the history that led to B

There was no rename. There was a copy in initial commit (and you cant say if it was Makefile copied into Makefile2 or vice verse). I dont believe it should really be called "rename", even if one of the copies was killed later.

>, rebase (actually the
> underlying "am -3" it calls is where this rename detection smart lies)
> applies the changes to the "renamed" path.

In this given case both Makefile1 and Makefile2 were absolutely equal. If rebase chose to edit Makefile2 why didnt it change Makefile1?

> 
> You might be able to work this around by forcing rebase not to use the
> simplified 3-way merge, by saying "rebase -m".

Yeah, it worked. ... CONFLICT (delete/modify): Makefile deleted in master and modified in HEAD~0. Version HEAD~0 of Makefile left in tree. ...

Though it does make me wonder why *simplified* 3-way merge is smarter than git merge ;)))

best regards,
  Fedor..