On Mon, Nov 10, 2008 at 03:14:42PM -0800, Junio C Hamano wrote:
quoted text
> 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!

quoted text
> 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 text
> 
> 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 text
> 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 text
>, 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 text
> 
> 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..
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html