filemerge: add support for partial conflict resolution by external tool
A common class of merge conflicts is in imports/#includes/etc. It's
relatively easy to write a tool that can resolve these conflicts,
perhaps by naively just unioning the statements and leaving any
cleanup to other tools to do later [1]. Such specialized tools cannot
generally resolve all conflicts in a file, of course. Let's therefore
call them "partial merge tools". Note that the internal simplemerge
algorithm is such a partial merge tool - one that only resolves
trivial "conflicts" where one side is unchanged or both sides change
in the same way.
One can also imagine having smarter language-aware partial tools that
merge the AST. It may be useful for such tools to interactively let
the user resolve any conflicts it can't resolve itself. However,
having the option of implementing it as a partial merge tool means
that the developer doesn't *need* to create a UI for it. Instead, the
user can resolve any remaining conflicts with their regular merge tool
(e.g. `:merge3` or `meld).
We don't currently have a way to let the user define such partial
merge tools. That's what this patch addresses. It lets the user
configure partial merge tools to run. Each tool can be configured to
run only on files matching certain patterns (e.g. "*.py"). The tool
takes three inputs (local, base, other) and resolves conflicts by
updating these in place. For example, let's say the inputs are these:
base:
```
import sys
def main():
print('Hello')
```
local:
```
import os
import sys
def main():
print('Hi')
```
other:
```
import re
import sys
def main():
print('Howdy')
```
A partial merge tool could now resolve the conflicting imports by
replacing the import statements in *all* files by the following
snippet, while leaving the remainder of the files unchanged.
```
import os
import re
import sys
```
As a result, simplemerge and any regular merge tool that runs after
the partial merge tool(s) will consider the imports to be
non-conflicting and will only present the conflict in `main()` to the
user.
Differential Revision: https://phab.mercurial-scm.org/D12356
$ hg init repo
$ cd repo
$ for n in 0 1 2 3 4 5 6 7 8 9 10 11; do
> echo $n > $n
> hg ci -qAm $n
> done
test revset support
$ cat <<'EOF' >> .hg/hgrc
> [extdata]
> filedata = file:extdata.txt
> notes = notes.txt
> shelldata = shell:cat extdata.txt | grep 2
> emptygrep = shell:cat extdata.txt | grep empty
> badparse = shell:cat badparse.txt
> EOF
$ cat <<'EOF' > extdata.txt
> 2 another comment on 2
> 3
> EOF
$ cat <<'EOF' > notes.txt
> f6ed this change is great!
> e834 this is buggy :(
> 0625 first post
> bogusnode gives no error
> a ambiguous node gives no error
> EOF
$ hg log -qr "extdata(filedata)"
2:f6ed99a58333
3:9de260b1e88e
$ hg log -qr "extdata(shelldata)"
2:f6ed99a58333
test weight of extdata() revset
$ hg debugrevspec -p optimized "extdata(filedata) & 3"
* optimized:
(andsmally
(func
(symbol 'extdata')
(symbol 'filedata'))
(symbol '3'))
3
test non-zero exit of shell command
$ hg log -qr "extdata(emptygrep)"
abort: extdata command 'cat extdata.txt | grep empty' failed: exited with status 1
[255]
test bad extdata() revset source
$ hg log -qr "extdata()"
hg: parse error: extdata takes at least 1 string argument
[10]
$ hg log -qr "extdata(unknown)"
abort: unknown extdata source 'unknown'
[255]
test a zero-exiting source that emits garbage to confuse the revset parser
$ cat > badparse.txt <<'EOF'
> +---------------------------------------+
> 9de260b1e88e
> EOF
It might be nice if this error message mentioned where the bad string
came from (eg line X of extdata source S), but the important thing is
that we don't crash before we can print the parse error.
$ hg log -qr "extdata(badparse)"
hg: parse error at 0: not a prefix: +
(+---------------------------------------+
^ here)
[10]
test template support:
$ hg log -r:3 -T "{node|short}{if(extdata('notes'), ' # {extdata('notes')}')}\n"
06254b906311 # first post
e8342c9a2ed1 # this is buggy :(
f6ed99a58333 # this change is great!
9de260b1e88e
test template cache:
$ hg log -r:3 -T '{rev} "{extdata("notes")}" "{extdata("shelldata")}"\n'
0 "first post" ""
1 "this is buggy :(" ""
2 "this change is great!" "another comment on 2"
3 "" ""
test bad extdata() template source
$ hg log -T "{extdata()}\n"
hg: parse error: extdata expects one argument
[10]
$ hg log -T "{extdata('unknown')}\n"
abort: unknown extdata source 'unknown'
[255]
$ hg log -T "{extdata(unknown)}\n"
hg: parse error: empty data source specified
(did you mean extdata('unknown')?)
[10]
$ hg log -T "{extdata('{unknown}')}\n"
hg: parse error: empty data source specified
[10]
we don't fix up relative file URLs, but we do run shell commands in repo root
$ mkdir sub
$ cd sub
$ hg log -qr "extdata(filedata)"
abort: error: $ENOENT$
[100]
$ hg log -qr "extdata(shelldata)"
2:f6ed99a58333
$ cd ..