From: Michael J Gruber <git@drmicha.warpmail.net>
To: "Gondek, Andreas" <Andreas.Gondek@dwpbank.de>,
Junio C Hamano <gitster@pobox.com>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: Git merge driver / attributes bug in 2.3.1?
Date: Mon, 09 Mar 2015 10:35:15 +0100 [thread overview]
Message-ID: <54FD6953.9030406@drmicha.warpmail.net> (raw)
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
prev parent reply other threads:[~2015-03-09 9:35 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-05 13:30 Git merge driver / attributes bug in 2.3.1? Gondek, Andreas
2015-03-05 18:55 ` Junio C Hamano
2015-03-06 11:25 ` Michael J Gruber
2015-03-06 13:31 ` AW: " Gondek, Andreas
2015-03-06 14:12 ` Michael J Gruber
2015-03-06 21:30 ` Junio C Hamano
2015-03-09 9:02 ` AW: " Gondek, Andreas
2015-03-09 9:35 ` Michael J Gruber [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54FD6953.9030406@drmicha.warpmail.net \
--to=git@drmicha.warpmail.net \
--cc=Andreas.Gondek@dwpbank.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).