On Mon, Nov 10, 2008 at 6:14 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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 -- 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
