Re: Letting tools partially resolve conflicts in a file

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux