I noticed that patch.py crashes on applying a specific patch. This is most easily discovered if you use hg crecord, and append some lines to the end of the tracked file. It then creates a git format diff which kills mercurial. This was tested with 1.4 which was on my Ubuntu 10.04 at the time and with 2.1+27-cb756482c1aa. Attaching traceback to this comment. In this traceback I run hg cr, which then creates a patch and tries to apply it.
The traceback.
Adding original-repo.tar.gz with pending changes. If you do hg cr on it, and just apply all the changes (by pressing c then y) then it crashes before it goes into vim for the commit message.
Adding buggy.diff which I have extracted from hg cr in the situation where it crashes (see original-repo.tar.gz and related comment). If you try to apply this patch to a repo which has been reset (i.e. pending changes have been aborted), then hg crashes in patch.py.
Adding original-repo-reset.tar.gz which contains the same repo, except the tracked file has been reverted to its original version; changes have been aborted. Those changes are (supposed to be) in buggy.diff; applying buggy.diff makes hg crash in patch.py.
Adding good.diff. I diffed the changed and original version of the tracked file; this came out. If you apply good.diff to original-repo-reset then hg does not crash. Notice that good.diff and buggy.diff are different (try to diff the diffs... whatever?). I think buggy.diff is probably correct, though. Keep in mind I am not acquainted with the format's spec.
Adding original-repo-try-patch.tar.gz. I used original-repo-reset and applied buggy.diff with patch < ../buggy.diff. It applied cleanly, except that the last hunk was moved a bit, which is funny, but that's probably something to fix in hg cr. However, hg cr probably uses something internal to hg to get this patch, so maybe that something internal should be using more context for when text is being appended to the end of a tracked file; I don't think the issue is in the hands of the maintainers of hg cr. Note that the order at the end of the file in original-repo (the one that crashes hg cr / patch.py) was roughly: sectionsP parseSections optionalP parseOptional getOptionalValue (the last three being new code) whereas after applying it is: optionalP parseOptional getOptionalValue sectionsP parseSections and the spacing is a bit messed up. If necessary, please open a separate issue about this, or maybe one exists already.
Adding original-repo-try-gooddiff.tar.gz, where I used the good.diff file to patch a copy of original-repo-reset. The outcome is correct and predictable. I patched using hg patch.
I was asked what "hg showconfig diff" shows, it is empty.
Patches submitted here: http://selenic.com/pipermail/mercurial-devel/2012-February/037998.html If you apply the patches above, Mercurial patching code behaves like a recent GNU Patch (it is interesting to note that the less recent (2.5.8) non-GNU patch on OSX 10.6 refuses to apply buggy.diff). About your last problem, I am afraid I will not look into now as it would mean looking at crecord code, and if I'd ever go that route, I would try improving the core record extension instead. Now, if you can exhibit two instances of a file generating one of these diffs lacking context I would be happy to look at it, that would be a bug in core mercurial diffing code. Thank you for this nice report.
Fixed by http://selenic.com/repo/hg/rev/b0c7525f826d Patrick Mezard <patrick@mezard.eu> patch: fix fuzzing of hunks without previous lines (issue3264) (please test the fix)
Confirming that the issue is fixed in latest hg. Notably it works better than using patch: patch would reorder the fuzzed hunk, whereas hg does not.
--- Bug imported by bugzilla@serpentine.com 2012-05-12 09:28 EDT --- This bug was previously known as _bug_ 3264 at http://mercurial.selenic.com/bts/issue3264 Imported an attachment (id=1632) Imported an attachment (id=1633) Imported an attachment (id=1634) Imported an attachment (id=1635) Imported an attachment (id=1636) Imported an attachment (id=1637) Imported an attachment (id=1638)