On Mon, Nov 10, 2008 at 03:14:42PM -0800, Junio C Hamano wrote:
> Fedor Sergeev <Fedor.Sergeev@xxxxxxx> 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!
> 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.
> 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..
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
