Letting tools partially resolve conflicts in a file

Letting tools partially resolve conflicts in a file

[Martin von Zweigbergk]

Hi,

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?

Thanks

Re: Letting tools partially resolve conflicts in a file

[Junio C Hamano]

Martin von Zweigbergk <martinvonz@gmail.com> 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 git-mergetool.sh::main() 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
backends.

Re: Letting tools partially resolve conflicts in a file

[Martin von Zweigbergk]

On Wed, Nov 24, 2021 at 1:21 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Martin von Zweigbergk <martinvonz@gmail.com> 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 would guess that it doesn't and I think that's what you concluded below.

> I tried to follow from git-mergetool.sh::main() 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.

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. Let me illustrate with an
example. Let's say you have this input:

base:
a
b
c
d

left:
a2
b
c
d2

right:
a3
b
c
d3

The tool now has some intelligence and decides that the conflict in
the first line should be resolved with a4, but it doesn't know how to
resolve the conflict in the last line. It then produces three outputs:

base:
a4
b
c
d

left:
a4
b
c
d2

right:
a4
b
c
d3

Obviously this scheme requires cooperation from the merge tool. That
seems fine as it only seems useful for tools that are designed for
partial conflict resolution. There should always be a regular merge
tool later in the chain after any tool that might produce a partial
resolution.

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

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.

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

Re: Letting tools partially resolve conflicts in a file

[Junio C Hamano]

Martin von Zweigbergk <martinvonz@gmail.com> 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.

Re: Letting tools partially resolve conflicts in a file

[Martin von Zweigbergk]

On Wed, Nov 24, 2021 at 2:16 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Martin von Zweigbergk <martinvonz@gmail.com> 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.