Will work on adding allowing merge tools to partially resolve conflicts

2021-11-29 Thread Martin von Zweigbergk via Mercurial-devel
Hi,

Just a heads up that 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. 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

The goal is to be able to write a language-aware merge tool that resolves
whatever conflicts it can and leaves the rest for a regular merge tool
(such as `meld` or `:merge3`).
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: Will work on adding allowing merge tools to partially resolve conflicts

2021-12-03 Thread Pierre-Yves David

On 11/30/21 12:29 AM, Martin von Zweigbergk via Mercurial-devel wrote:

Hi,

Just a heads up that


Thanks for the heads up !

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.


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 ?


Cheers,

--

Pierre-Yves David

___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel


Re: Will work on adding allowing merge tools to partially resolve conflicts

2021-12-03 Thread Martin von Zweigbergk via Mercurial-devel
On Fri, Dec 3, 2021 at 7:23 AM Pierre-Yves David <
pierre-yves.da...@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..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 = 
merge-includes.args = $base $local $other
merge-imports.executable = 
python-merge.executable = 

[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/`.
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel