Re: Git merge driver / attributes bug in 2.3.1?

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

Michael J Gruber <git@drmicha.warpmail.net> writes:

> Gondek, Andreas venit, vidit, dixit 06.03.2015 14:31:
>> The archive contains my test repository, the merge driver and the
> .gitconfig of the user. We don't have a global .gitconfig.
>
> Thanks for the test repo!
>
> Alas, the merge driver gets executed with v1.9.0-rc3, v1.8.5 and v1.7.0,
> at least over here - as it should be because of the conflict: two
> patches changing the same file. That conflict can be resolved
> automatically by the internal driver, of course.

That matches my expectation.  The whole point to have the merge
driver plug-in mechanism is to allow overriding the internal textual
3-way file-level merge, so we would have always called out to the
custom driver when the tree-level merge machinery says that the
content needs a file-level merge [*1*].


[Footnote]

*1* This is a tangent, but I've been wondering if we want some cases
where the tree-level merge machinery currently says that there is no
need for file-level merge to be fed to the merge driver.

Specifically, the tree-level merge machinery considers a case where
you and the other party changed the files identically to be cleanly
merged, but for contents of certain nature, that may not be always
desirable.

Imagine that I and my wife are sharing a note to record what is in
our refrigerator.  After I buy a carton of milk, I'd do

    $ echo "1 carton of milk" >>fridge.txt
    $ git commit && git push

and my wife would do the same.

    $ echo "1 carton of milk" >>fridge.txt
    $ git commit && git push

which would not fast-forward, and then she would

    $ git pull

which would result in only one carton of milk in our fridge, even
though when both of us got home, we will realize that we now have
two of them.