Martin von Zweigbergk [off-list ref] 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.
On Wed, Nov 24, 2021 at 1:21 PM Junio C Hamano [off-list ref] wrote:
Martin von Zweigbergk [off-list ref] writes:
quoted
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.