list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Martin von Zweigbergk <>
To: Junio C Hamano <>
Cc: git <>
Subject: Re: Letting tools partially resolve conflicts in a file
Date: Wed, 24 Nov 2021 14:32:39 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <xmqqwnkx9p40.fsf@gitster.g>

On Wed, Nov 24, 2021 at 2:16 PM Junio C Hamano <> wrote:
> Martin von Zweigbergk <> writes:
> > The solution I had in mind for letting merge tools communicate partial
> > resolution was to let them take 3 inputs (as today) and produce 3
> > outputs (perhaps by overwriting its 3 inputs). That way they can leave
> > conflicts in a conflict-marker-agnostic way. ...
> >
> > Correct. My team at work hopes to create a language-aware mergetool.
> > The "#includes and imports" I mentioned is just one case that such a
> > tool could resolve. Hopefully it can also figure out cases like where
> > both sides modify an array (on a single line), or where an expression
> > is modified on one side and re-wrapped on the other. The thing is that
> > it will obviously not be able to handle *all* conflicts, so we want to
> > leave remaining conflicts for the user, so that's where this idea
> > comes in. I don't foresee having more than one such tool in the chain
> > before the user gets involved.
> Hmph, OK, so the part I guessed that more than one such tools are
> chained together was incorrect.  I do not find it too implausible to
> wish to first let the "include/import" tool to clean up the fallout
> of renaming the include/module files this source depends on, and
> then let the "renamed variable" tool to handle the fallout of
> renaming a local variable in a file in this source file, in this
> order or the other way around.  It may be a tall order to write a
> tool that can handle *all* coflicts, but it would be a nice future
> to see that multiple tools, each of which specializing one corner of
> its own, work well together.

Yep, I agree that it's desirable to allow multiple tools in the chain,
even though we don't currently have any plans for more than one tool
in it (plus the final "interactive" tool). And to be honest, we won't
even be using Git (this project is done in the scope of Google's
Mercurial-based tool). However, if the project to write a
language-aware tool works out, it should of course also be useful for
Git projects.

      reply	other threads:[~2021-11-24 22:32 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
2021-11-24 22:03   ` Martin von Zweigbergk
2021-11-24 22:15     ` Junio C Hamano
2021-11-24 22:32       ` Martin von Zweigbergk [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:

  List information:

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

  git send-email \ \ \ \ \
    --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).