Will work on adding allowing merge tools to partially resolve conflicts

[Martin von Zweigbergk]

On Fri, Dec 3, 2021 at 7:23 AM Pierre-Yves David <
pierre-yves.david at ens-lyon.org> wrote:

> On 11/30/21 12:29 AM, Martin von Zweigbergk via Mercurial-devel wrote:
> > I will work on teaching the merge machinery to call external merge
> > tools to let them partially resolve a merge. That will require a
> > different protocol for interacting with the merge tool. We're going to
> > pass the merge tool 3 inputs and expect 3 possibly modified
> > outputs, instead of just a single output the way existing merge tools
> > work. That way they can leave conflicts in a conflict-marker-agnostic
> way.
>
>
> The feature seems a great idea. This is somewhat related to the
> "premerge" option that mergetools currently have ( see hg help
> config.merge-tools.premerge ). Except more than just the internal option
> will be available.


Yes, agreed. Speaking of that, it would be nice to separate out a config
for conflict marker style (so it's not repeated in the
`merge-tools.<tool>.premerge` and `ui.merge`). I won't promise I'll get
around to that, but I'll try.

What do you plan in terms of user interface/config for this ? It would
> be nice if it the result feels like it extend the `premerge` option
> smoothly.
>
> I assume you will want to be able to configure the pre-merge tools
> according to the file pattern, and mostly "regardless" of end user merge
> tool of choice. What's your thoughts here ?
>

Yes, I think they would be independent of the final (current) merge tool.
As you said, we'll want to allow these new merge tools per file pattern. It
should also be possible to configure several of them in a chain. So maybe
something like this:
```
[partial-merge-tools]
merge-includes.executable = <path>
merge-includes.args = $base $local $other
merge-imports.executable = <path>
python-merge.executable = <path>

[partial-merge-patterns]
**.c = merge-includes
**.h = merge-includes
# Yes, "python-merge" would presumably also be able to merge imports, so it
should be enough with just that in the list.
# Let's say merge-imports is much faster or something for the sake of this
example.
**.py = merge-imports, python-merge
```

I think the high-level file merge process would be something like this:

1. Attempt simplemerge (unless the config for the final merge tool has
`premerge = false` etc.). If it succeeds, we're done.
2. Attempt each partial merge tool, in the specified order. If the three
files are equal afterwards, we're done.
3. Run simplemerge again (unless the config for the final merge tool has
`premerge = false` etc.). If it succeeds, we're done.
4. Run the final merge tool.

I'm not sure if the partial merge tools should run when `premerge = false`.
I think we'll at least want to skip them when you do e.g. `-t :local/`.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20211203/2b91154d/attachment-0002.html>