From: Junio C Hamano <gitster@pobox.com>
To: "Philip Oakley" <philipoakley@iee.org>
Cc: "Git List" <git@vger.kernel.org>
Subject: Re: mergetool: what to do about deleting precious files?
Date: Tue, 30 May 2017 09:52:56 +0900 [thread overview]
Message-ID: <xmqq1sr7f9nb.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <DE497A69E68043DABF9C3A7D9198B277@PhilipOakley> (Philip Oakley's message of "Mon, 29 May 2017 13:57:08 +0100")
"Philip Oakley" <philipoakley@iee.org> writes:
> If I now understand correctly, the merge process flow is:
>
> * canonicalise content (eol, smudge-clean, $id, renormalise, etc)
> * diff the content (internal, or GIT_EXTERNAL_DIFF)
> * apply the diff
> * if conflicts, only then use merge-driver/tool
>
> Would that be a correct interpretation?
Not quite. There are a lot more going on before any of those steps:
* Find the common ancestor commit (which could be many).
* Walk the three trees (the common ancestor's, ours and theirs) in
parallel, noticing what happened to each path. Depending on what
happened to the path in each branch, the merge may or may not
"conflict" (e.g. when both sides added exactly the same contents
to the same path, they are not counted as conflicting. when we
removed while they modified, they show as conflicting).
* For paths that are conflicting, feed the canonicalized content of
the versions from common, ours and theirs to the file-level merge
driver. The builtin file-level merge driver takes two xdiff (one
between ancestor and ours, the other between ancestore and
theirs) and reconciles them to produce the result. But that is
irrelevant in the context of "custom merge driver"; the builtin
one is skipped altogether and the custom contents merge driver
the user specified via the attributes is used instead.
Notice that the second step above has no customization knobs. Any
path the second step deems not to conflict is "merged cleanly"
without even triggering the "oops, ours and theirs did conflicting
changes, to the content; let's see how the final content should look
like" (aka the third step). This is *not* because "Git knows the
best"; it is merely that nobody felt the need for a mechanism to
allow customizing the second step.
And that is why I said you need a new customization mechanism if you
want to affect the outcome of the scenario that started this thread.
next prev parent reply other threads:[~2017-05-30 0:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-27 10:03 mergetool: what to do about deleting precious files? Philip Oakley
2017-05-28 1:14 ` Junio C Hamano
2017-05-28 10:24 ` Philip Oakley
2017-05-28 13:06 ` Junio C Hamano
2017-05-29 12:57 ` Philip Oakley
2017-05-30 0:52 ` Junio C Hamano [this message]
2017-05-30 23:04 ` Philip Oakley
2017-05-31 0:02 ` 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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq1sr7f9nb.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=philipoakley@iee.org \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).