All of lore.kernel.org
 help / color / mirror / Atom feed
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

      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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.