Re: overly smart rebase - bug or feature?

From: Avery Pennarun <apenwarr@gmail.com>
Date: Nov 10, 2008, 23:31 UTC
Message-ID: <32541b130811101531r4b92edc3wfdfb49dc0e5119f4@mail.gmail.com>
In-Reply-To: <7vod0n41i5.fsf@gitster.siamese.dyndns.org>

On Mon, Nov 10, 2008 at 6:14 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 6 quoted lines

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

But isn't rename detection in this case rather suspicious, since:

- the preimage already had Makefile, Makefile1, and Makefile2, thus it
is not a rename, but at most a copy, and not even a newly-created copy
in either branch;

- *two* different files match the original Makefile, but rebase has
randomly selected one but not the other;

- (I haven't verified this claim) cherry-pick and merge both correctly
identify the problem as a delete/modify conflict?

It seems that rebase should have bailed out for at least one of these three reasons.

Avery