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).
Mon, 13 Feb 2012 16:47:31 +0100 patch: fix fuzzing of hunks without previous lines (issue3264) stable
Patrick Mezard <patrick@mezard.eu> [Mon, 13 Feb 2012 16:47:31 +0100] rev 16123
patch: fix fuzzing of hunks without previous lines (issue3264) When applying hunks such as: @@ -2,1 +2,2 @@ context +change fuzzing would empty the "old" block and make patchfile.apply() traceback. Instead, we apply the new block at specified location without testing. The "bottom hunk" test was removed as patch(1) has no problem applying hunk with no context in the middle of a file.
Mon, 13 Feb 2012 13:51:38 +0100 patch: make hunk.fuzzit() compute the fuzzed start locations stable
Patrick Mezard <patrick@mezard.eu> [Mon, 13 Feb 2012 13:51:38 +0100] rev 16122
patch: make hunk.fuzzit() compute the fuzzed start locations - It moves hunks processing weirdness where it belongs - It helps reusing said weirdness whenever fuzzit() is called, like during the actual hunk fuzzing.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -4 +4 +10 +30 +100 +300 +1000 +3000 +10000 +30000 tip