Re: Git merge driver / attributes bug in 2.3.1?

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Mar 9, 2015, 09:35 UTC
Message-ID: <54FD6953.9030406@drmicha.warpmail.net>
In-Reply-To: <D8780C527EB1E642B3150E6D705B46D448E8063B@DWPWHMS531.dwpbank.local>

Gondek, Andreas venit, vidit, dixit 09.03.2015 10:02:

> 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.

That is the first issue: Can you reproduce with an older Git and your test repo the effect that you wanted to achieve?

I have tried a few older Git's with your test repo, and I always get the same behavior as with current Git (and as we would expect). So, something else has to be going on here.

> 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?

First, the tree level merge checks whether the two sides introduce different changes to the same files. If not a simple tree level merge is done (which may or may not be OK, see Junio's shopping list example).

If yes (different changes to the same files), a merge driver is used, either an external one if specified, or the internal 3-way merge driver. But I'm not a merge expert ;)

If I understand correctly, you want to use the external merge driver to signal a conflict that git may miss otherwise?

On a side note, this discussion and the shopping list example show how badly a tool like git-dep(endency) can go wrong, just like the automatic merge. Just imagine a library change on one branch, and the introduction of a new call site following the old library calling convention on another branch. No dependency detected, clean tree-level merge by git, and fails to compile (hopefully) or run (worse). Automatic mergers can only guess, they are no code analyzers.

Michael