Re: [PATCH 3/4] merge-recursive: improve auto-merging messages with path collisions

[Junio C Hamano <gitster@pobox.com>]

Elijah Newren <newren@gmail.com> writes:

> Each individual file involved in a rename could have also been modified
> on both sides of history, meaning it may need to have content merges.
> If two such files are renamed into the same location, then on top of the
> two natural auto-merging messages we also have to two-way merge the
> result, giving us messages that look like
>
>   Auto-merging somefile.c (was somecase.c)
>   Auto-merging somefile.c (was somefolder.c)
>   Auto-merging somefile.c
>
> However, despite the fact that I was the one who put the "(was %s)"
> portions into the messages (and just a few months ago), I was still
> initially confused when running into a rename/rename(2to1) case and
> wondered if somefile.c had been merged three times.  Update this to
> instead be:
>
>   Auto-merging version of somefile.c from somecase.c
>   Auto-merging version of somefile.c from someportfolio.c
>   Auto-merging somefile.c
>
> This is an admittedly long set of messages for a single path, but you
> only get all three messages when dealing with the rare case of a
> rename/rename(2to1) conflict where both sides of both original files
> were also modified, in conflicting ways.

Yeah, that does look mouthful, but definitely is more
understandable.