All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Philip Oakley <philipoakley@iee.email>
Cc: Edmundo Carmona Antoranz <eantoranz@gmail.com>,
	Git List <git@vger.kernel.org>
Subject: Re: conflict markers on recursive strategy with diff3 enabled
Date: Tue, 29 Oct 2019 10:31:56 +0900	[thread overview]
Message-ID: <xmqqlft48hgz.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <e26d24b2-6fca-8546-f2b3-bf4660db8184@iee.email> (Philip Oakley's message of "Mon, 28 Oct 2019 22:13:02 +0000")

Philip Oakley <philipoakley@iee.email> writes:

> I believe this happens when no merge-base is found between the two
> lines of development that are being merged, so a fake merge-base is
> created to allow the regular 3-way merge to occur.

s/no merge-base is/more than one merge-base are/; then a synthetic
merge base is computed in order to perform the merge the end-user
requested first, and the computation of that synthetic merge base
may involve merge conflicts.  After that, the merge logic pretends
that the two versions being merged both derived from such a common
ancestor version _with_ conflict markers in it, and may conflict
with each other around that existing (inner) conflict markers to
leave a rather messy result.  It is particularly bad when both
branches did the same thing only on one side the inner merge
conflicted but not on the other side---one side of inner conflict
marker (say "<<<<<<<<") may disappear when the merged branches made
the same change (so "both side changed identically, resolve to their
same result" 3-way merge rule would apply) and around that area the
result will not have the conflict marker from the inner merge, and
the other side will say "one side made into this shape, the other
side made into that shape, from this common ancestor version" in the
diff3 format, which would mean that we would see conflict marker
lines from the inner merge between "|||||" and "=====" lines in the
outer merge (i.e. the common ancestor version).  The conflict
markers of the inner merge are longer than those of the outermost
merge, so you could sift them by careful eyeballing, but it is
rather hard to read.


      reply	other threads:[~2019-10-29  1:32 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-25  0:13 conflict markers on recursive strategy with diff3 enabled Edmundo Carmona Antoranz
2019-10-28 21:58 ` Elijah Newren
2019-10-28 22:13 ` Philip Oakley
2019-10-29  1:31   ` Junio C Hamano [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=xmqqlft48hgz.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=eantoranz@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=philipoakley@iee.email \
    /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.