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