Matt Mackall <mpm@selenic.com> [Thu, 16 Feb 2012 15:58:51 -0600] rev 16127
filemerge: remove some redundancy in decorators/docstrings
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 12 Feb 2012 21:38:12 +0900] rev 16126
filemerge: create detail of internal merge tools from documentation string
this patch introduces 'internaltoolsmarker' which creates detail of
each internal merge tools from documentation string for 'hg help merge-tools'.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 12 Feb 2012 21:38:12 +0900] rev 16125
filemerge: refactoring of 'filemerge()'
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.
Patrick Mezard <patrick@mezard.eu> [Mon, 13 Feb 2012 17:22:35 +0100] rev 16124
patch: fuzz more aggressively to match patch(1) behaviour
The previous code was assuming a default context of 3 lines. When fuzzing, it
would take this value in account to reduce the amount of removed line from
hunks top or bottom. For instance, if a hunk has only 2 lines of bottom
context, fuzzing with fuzz=1 would do nothing and with fuzz=2 it would remove
one of those lines. A hunk with one line of bottom context could not be fuzzed
at all. patch(1) has apparently no such restrictions and takes the fuzz level
at face value.
- test-import.t: fuzz/offset changes at the beginning of file are explained by
the new fuzzing behaviour and match patch(1) ones. Patching locations are
different but those of my patch(1) do not make a lot of sense right now
(patched output are the same)
- test-import-bypass.t: more agressive fuzzing makes a patching supposed to
fail because of context, succeed. Change the diff to avoid this.
- test-mq-merge.t: more agressive fuzzing would allow the merged patch to apply
with fuzz, but fortunately we disallow this behaviour. The new output is
kept.
I have not enough experience with patch(1) fuzzing to know whether aligning our
implementation on it is a good or bad idea. Until now, it has been the
implementation reference. For instance, "qpush" tolerates fuzz (test-mq-merge.t
runs the special case of pushing merge revisions where fuzzing is forbidden).