Thu, 16 Feb 2012 15:58:51 -0600 filemerge: remove some redundancy in decorators/docstrings
Matt Mackall <mpm@selenic.com> [Thu, 16 Feb 2012 15:58:51 -0600] rev 16127
filemerge: remove some redundancy in decorators/docstrings
Sun, 12 Feb 2012 21:38:12 +0900 filemerge: create detail of internal merge tools from documentation string
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'.
Sun, 12 Feb 2012 21:38:12 +0900 filemerge: refactoring of 'filemerge()'
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.
Mon, 13 Feb 2012 17:22:35 +0100 patch: fuzz more aggressively to match patch(1) behaviour stable
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).
(0) -10000 -3000 -1000 -300 -100 -30 -10 -4 +4 +10 +30 +100 +300 +1000 +3000 +10000 +30000 tip