archive mirror
 help / color / mirror / Atom feed
From: Elijah Newren <>
To: Edmundo Carmona Antoranz <>
Cc: Git List <>
Subject: Re: conflict markers on recursive strategy with diff3 enabled
Date: Mon, 28 Oct 2019 14:58:39 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hi Edmundo,

On Fri, Oct 25, 2019 at 12:19 PM Edmundo Carmona Antoranz
<> wrote:
> Hi!
> I'm sitting down hunting for conflict examples and while looking
> through past conflicts in git I found one that has a format that I
> hadn't seen before. When merging the parents of 8b79343fc0 we get
> this:
> <<<<<<< HEAD
> /*
> * Unlink the .pack and associated extension files.
> * Does not unlink if 'force_delete' is false and the pack-file is
> * marked as ".keep".
> */
> extern void unlink_pack_path(const char *pack_name, int force_delete);
> ||||||| merged common ancestors
> >>>>>>>>> Temporary merge branch 2
> =======
> >>>>>>> 8b79343fc0^2
> That is with merge.conflictStyle set to diff3. What I would like to
> know is if the details about how the additional information that is
> not normally seen on a conflict has to be interpreted (to be read as
> "the part about the temporary branches"). I see some explanation about
> it in [1] but when checking inside "git help merge" all I see is that
> when you are using diff3 you will get the content of the parent but
> there's more stuff than just that. Is it documented somewhere?

The "||||||| merged common ancestors" section shows the content of the
merge base, which itself contained conflict markers.

The way the merge base can itself have conflict markers is as follows:
when you go to merge your two branches, git finds that there isn't a
unique merge base for doing the three-way merge.  You, in fact, have
more than one merge base.  And so, it first merges those (and if those
don't have a unique merge base, then their merge bases must first be
merged...and so on -- thus the name of "recursive" for the merge
algorithm).  When the algorithm runs into conflicts while merging the
merge bases, it simply accepts the version of the file with the
conflict markers as the correct resolution (because it has to pick
something, and that is unlikely to erroneously match the outer
contents on either side).

Thus when using diff3 conflict style, you can sometimes see nested
conflict markers.  And technically you can construct weird histories
where you have arbitrarily deeply nested conflict markers as well, but
it certainly isn't very common.

Hope that helps,

  reply	other threads:[~2019-10-28 21:58 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 [this message]
2019-10-28 22:13 ` Philip Oakley
2019-10-29  1:31   ` Junio C Hamano

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

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