Re: Custom merge driver with no rename detection

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 15, 2016, 09:57 UTC
Message-ID: <xmqqlh6mqors.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <alpine.DEB.2.20.1602150854520.2964@virtualbox>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 18 quoted lines

> On Sun, 14 Feb 2016, Junio C Hamano wrote:
>
>> Felipe Gonçalves Assis <felipeg.assis@gmail.com> writes:
>> 
>> > The usual workaround is using the resolve strategy, but apparently it
>> > ignores the custom merge driver.
>> 
>> Hmph.
>> 
>> Indeed, git-merge-file seems to call xdl_merge() directly, bypassing
>> the ll_merge(), which is understandable as the former predates the
>> latter.  That needs to be fixed, I think.
>
> I think this is by design. (Because I designed it.)
>
> The original idea of git-merge-file was to serve as a drop-in replacement
> for GNU/BSD merge when you want to avoid to be subject to the vagaries of
> the GNU vs BSD implementations.

We did use to use "merge" from the RCS suite originally, and we did want to use our own, but the primary reason we added our own was so that it can be enhanced in sync with the remainder of Git in a consistent way.

If the rest of Git can be told via the attribute system to make use of a three-way merge driver, it should have learnt the trick to be kept up with the rest of the system. I see the current state of the program merely be staying a bit behind; I do not think it was part of the grand design to forbidd it forever from learning new optional tricks.