More generally, MQ does not correctly handle encode/decode hooks:


$ hg init
$ (echo '[encode]'; echo '*.r13=rot13'; echo '[decode]'; echo '*.r13=rot13') >
.hg/hgrc
$ echo hello there > plaintext
$ echo uryyb jbeyq > secret.r13
$ hg ci -A -m init
adding plaintext
adding secret.r13
$ hg cat secret.r13 
hello world
$ hg qinit
$ hg qnew -m test x.diff
$ echo uryyb ntnva >> secret.r13
$ hg qref
$ hg qhead
test
$ hg qdiff
diff --git a/secret.r13 b/secret.r13
--- a/secret.r13
+++ b/secret.r13
@@ -1,1 +1,2 @@
 hello world
+hello again
$ cat .hg/patches/x.diff 
test

diff --git a/secret.r13 b/secret.r13
--- a/secret.r13
+++ b/secret.r13
@@ -1,1 +1,2 @@
 hello world
+hello again
$ hg qpop
Patch queue now empty
$ cat secret.r13 
uryyb jbeyq
$ hg qpush
applying x.diff
patching file secret.r13
Hunk #1 FAILED at 0
1 out of 1 hunk FAILED -- saving rejects to file secret.r13.rej
patch failed, unable to continue (try -v)
patch failed, rejects left in working dir
Errors during apply, please fix and refresh x.diff
$ cat secret.r13
uryyb jbeyq
$ cat secret.r13.rej 
--- secret.r13
+++ secret.r13
@@ -1,1 +1,2 @@
 hello world
+hello again
$ 


This causes problems when using http://wiki.netbeans.org/HgExternalBinaries to
manage external files.

> As stated in the related issue, this would be easier now patches are handled
internally.

Problem is we still allow third-parties patch programs. It's very tempting to
drop the support for those because several issues require more control on the
patching process (at least issue752 and the current one). Then we would have 
patch.patch() and something like patch.patchrepo() with much more logic in it.

I can't get MQ to play nicely with text encoding/decoding: On files with
CRLF encoding/decoding, patching always fails---regardless of whether I
use the internal patcher or GnuWin32's.

Issue483 is related, but the fix there does nothing for MQ.

A reply from Patrick Mézard says:

You are right, the issue is still the same: the patches are generated from the 
repository file version while the patching code operates on the working 
directory, thus the LF/CRLF discrepancy. It can be fixed by making the patching 
code roundtripping through encoding/decoding filters. As stated in the related 
issue, this would be easier now patches are handled internally. Could you open 
an issue about that ?