AW: Git merge driver / attributes bug in 2.3.1?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



We used a merge driver to create a conflict semaphore file whenever a merge conflict occurs in Atlassian Stash. This worked for several month until we got to update our Git version because of another problem.

If I understand it correctly, a merge driver is executed before the normal internal merge happens? So I would need to call a git merge-file in my merge driver, test the result and return the exit code of the git merge-file?

Greetings

Andreas Gondek
Applications
________________________________

Deutsche WertpapierService Bank AG
ITTAS
Derendorfer Allee 2
40476 Düsseldorf
Tel.: +49 69 5099 9503
Fax: +49 69 5099 85 9503
E-Mail: Andreas.Gondek@xxxxxxxxxx
http://www.dwpbank.de

Deutsche WertpapierService Bank AG | Wildunger Straße 14 | 60487 Frankfurt am Main 
Sitz der AG: Frankfurt am Main, HRB 56913 | USt.-ID: DE 813759005 
Vorstand: Thomas Klanten, Dr. Christian Tonnesen
Aufsichtsrat: Wilfried Groos (Vors.)

-----Ursprüngliche Nachricht-----
Von: Junio C Hamano [mailto:gitster@xxxxxxxxx] 
Gesendet: Freitag, 6. März 2015 22:30
An: Michael J Gruber
Cc: Gondek, Andreas; git@xxxxxxxxxxxxxxx
Betreff: Re: Git merge driver / attributes bug in 2.3.1?

Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> 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.
--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]