A follow-up to 6847621b4da6.
internal:merge should never be picked for merging symlinks ... but in the test
suite we have HGMERGE="internal:merge" which bypasses all the usual merge-tool
cleverness. Without any output it can be hard to figure out what happened and
where the problem is.
Simplemerge is not symlink aware and will never do the the right thing on
symlinks. It would read the symlink as a file and abort with 'No such file or
directory' on dangling symlinks.
Instead, internal:merge now simply fails to merge symlinks.
current 'filemerge.filemerge()' implementation is verfy complicated.
- it is not easy to add new internal merge tools
(only by patching on 'filemerge()', or replacing it completely)
- cleanup of temporary files is unsatisfactory
('internal:dump' does not, in fact)
this is patch for refactoring of 'filemerge()' to isolate each
internal merge tool implementations from 'filemerge()', and clean up
common part in it.
hgrc(5) already implies that this works, so we might as well support it.
Another approach would be to implement this in util.findexe(): that
would benefit other callers of findexe(), e.g. convert and anyone
calling the user's editor. But findexe() is really implemented in
both posix.py and windows.py, so this would make both of those modules
depend on util.py: not good. So keep it narrow and only for merge
tools.
These leaks may occur in environments that don't employ a reference
counting GC, i.e. PyPy.
This implies:
- changing opener(...).read() calls to opener.read(...)
- changing opener(...).write() calls to opener.write(...)
- changing open(...).read(...) to util.readfile(...)
- changing open(...).write(...) to util.writefile(...)
This allows us to provide alternate search keys for 64bit operating systems that
may have 32bit merge tools installed. Presumably it may find other uses.
ui.forcemerge is set before calling into merge or resolve commands, then unset
to prevent ui pollution for further operations.
ui.forcemerge takes precedence over HGMERGE, but mimics HGMERGE behavior if the
given --tool is not found by the merge-tools machinery. This makes it possible
to do: hg resolve --tool="python mymerge.py" FILE
With this approach, HGMERGE and ui.merge are not harmed by --tool
re.match only looks at the beginning of the merged file, and without
re.MULTILINE the file had to end with ">>>>>>> something".
Now conflict markers inside the file are found, too.
util.interpolate can be used to replace multiple items in a string all at once
(and optionally apply a function to the replacement), without worrying about
recursing:
>>> import util
>>> s = '$foo, $spam'
>>> util.interpolate(r'\$', { 'foo': 'bar', 'spam': 'eggs' }, s)
'bar, eggs'
>>> util.interpolate(r'\$', { 'foo': 'spam', 'spam': 'foo' }, s)
'spam, foo'
>>> util.interpolate(r'\$', { 'foo': 'spam', 'spam': 'foo' }, s, lambda s: s.upper())
'SPAM, FOO'
The patch also changes filemerge.py to use this new function.
tool.check is a list of check options, and can be used in place of
tool.checkchanged and tool.checkconflicts:
Equivalences:
tool.checkchanged = yes
tool.checkconflicts = no
tool.check = changed
tool.checkchanged = no
tool.checkconflicts = yes
tool.check = conflicts
tool.checkchanged = yes
tool.checkconflicts = yes
tool.check = changed, conflicts
Add _toollist() wrapper for ui.configlist() to implement this consistently.
checkchanged and checkconflicts are still supported, but check is
preferred for implementing new check options.
Merge tools will be able to exploit this to correctly merge backouts.
This won't work fully, though, until issue 1327 is solved, since the
node information is not necessarily correct.
Use ampersands (&) to delineate the response char in each choice.
ui.prompt() responses are now explicitly case insensitive. GUIs
that subclass ui can generate dialogs from the full choice names.
