Re: overly smart rebase - bug or feature?

Fedor Sergeev [off-list ref] writes:

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

quoted

Fedor Sergeev [off-list ref] writes:

quoted

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!

quoted

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.

quoted

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.

quoted

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.

quoted

, 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?

quoted

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 ;)))

Simplified one is not _smarter_.  It is merely _faster_, exactly because
it only looks at the paths between A^..A and nothing else.

And that is why it cannot tell between the case where both A^ and A have
Makefile2 or they both lack it.  And that is exactly why application of
this change on top of B is mistaken as a patch to a renamed path.  From
B's point of view:

 - Incoming change says "I changed Makefile from this shape to that
   shape", and nothing else;

 - B does not have Makefile, but it happens to have the contents at path
   Makefile2 that is identical to the preimage of that incoming change.

which makes it guess (when falling back to 3-way merge) that somewhere
leading to B what used to be at Makefile (which is what the incoming
change claims to change) may have been renamed to Makefile2 (because B
does not have Makefile but does have it).