Re: Letting tools partially resolve conflicts in a file

[Martin von Zweigbergk <martinvonz@gmail.com>]

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