list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <>
To: Martin von Zweigbergk <>
Cc: git <>
Subject: Re: Letting tools partially resolve conflicts in a file
Date: Wed, 24 Nov 2021 13:20:58 -0800	[thread overview]
Message-ID: <xmqqmtltz1vp.fsf@gitster.g> (raw)
In-Reply-To: <> (Martin von Zweigbergk's message of "Wed, 24 Nov 2021 08:31:19 -0800")

Martin von Zweigbergk <> writes:

> I've searched the list and not found anything about this topic, but I
> figured I'd ask to be sure. The question is not specific to Git, but
> this seems like a forum where it might have been brought up.
> You could imagine having a merge tool that was specialized for some
> purpose and only able to resolve a particular kind of conflict. An
> example would be a tool that resolves conflicts in `#include` lines or
> `import` lines. It could be useful to have such tools run as part of a
> chain of merge tools, where the final merge tool is what users
> normally have configured (such as `meld`, or the internal "attempt
> merge, or leave conflict markers" tool).
> Has this problem come up before?

I do not recall seeing such a topic, but I am not sure how practical
your idea is to implement from the Git side.

As a zeroth order approximation, instead of such a half-auto-merge
tool, while resolving a conflicted merge with two conflicted hunks
in a file, if you hand edit one conflicted hunk and then run "git
mergetool", is your "half resolution by hand" seen by the mergetool
backend correctly?

I tried to follow from what happens.  Each
path is given to merge_file() helper function, and three temporary
files, $BASE, $LOCAL, and $REMOTE, are prepared from the blob object
registered in the index at stages #1, #2 and #3.  A mergetool
backend, e.g. mergetools/meld, looks at these three files in its
merge_cmd() function.

Notice that the contents in the working tree file after a conflicted
auto-merge does not even get looked at by the mergetool backend in
the above picture?  I am not sure if replacing the contents of LOCAL
with your half-resolved contents would give us the behaviour you
want.  If it were the case, perhaps vanilla "git mergetools" would
have fed the current file in the working tree, which was half
resolved by "git merge" with conflict markers, as LOCAL to the
mergetool backend even before we started discussing this topic, so I
am not that optimistic.

I assume that your idea is that various small "I know how to resolve
only this kind of conflicts" tools can plug into a larger merge
helper framework to improve end-user experience, and I find the idea
intriguing.  I would be surprised if such an idea has never been
discussed by folks in projects that develop and maintain merge
helpers, like meld and kompare.  But I am not convinced if it is a
good idea to do that on our side, before we spawn these mergetool

  reply	other threads:[~2021-11-24 21:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-24 16:31 Martin von Zweigbergk
2021-11-24 21:20 ` Junio C Hamano [this message]
2021-11-24 22:03   ` Martin von Zweigbergk
2021-11-24 22:15     ` Junio C Hamano
2021-11-24 22:32       ` Martin von Zweigbergk

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:

  List information:

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

  git send-email \
    --in-reply-to=xmqqmtltz1vp.fsf@gitster.g \ \ \ \
    --subject='Re: Letting tools partially resolve conflicts in a file' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Code repositories for project(s) associated with this inbox:

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