git-apply can't apply patches to CRLF-files

Hello,

git-apply can't apply the patch to file with windows-style CRLF line endings, even if the patch was generated by git-format-patch.

Is this a bug or known deficiency?

The following script reproduces the problem
---------
#!/bin/sh
set -e
mkdir trash
cd trash
git init-db
echo "abc" > a
unix2dos a
git add a
git commit -m "a added" a
echo "cde" >> a
unix2dos a
git commit -m "a modified" a
git format-patch HEAD^
git reset --hard HEAD^
git am 0001*.txt
---------

The resulting output is
---------

$ ./test
defaulting to local storage area
a: done.
Committing initial tree 357c56061b96c1548b15168bc0d02e8d1a319e0b
a: done.
0001-a-modified.txt

Applying 'a modified'

error: patch failed: a:1
error: a: patch does not apply
Patch failed at 0001.
When you have resolved this problem run "git-am --resolved". If you would prefer to skip this patch, instead run "git-am --skip".
---------

If I remove unix2dos calls and so the file has normal unix LF line endings, then the result is correct as expected

---------

$ ./test
defaulting to local storage area
Committing initial tree 6afc8719a182fed19980da0e53d13fba1f94dd3f
0001-a-modified.txt

Applying 'a modified'

Wrote tree 49f5181a399bbcaac1da3bf693c466a281c4a255
Committed: 2b0a2936d0a65b3511882b8e88586ab054dd15b2
---------

I do not think that is the case.

This particular reproduction recipe looks like a PEBCAK; it does not reproduce for me, but I do not have/use unix2dos so I did DOSsy line endings a bit differently.

git init-db
echo 'abc@' | tr '[@]' '[\015]' >a
git add a
git commit -m initial
echo 'def@' | tr '[@]' '[\015]' >>a
git commit -a -m second
git format-patch HEAD^
git reset --hard HEAD^
git am 0*.txt

Here the first line of a ends with \r\n already end the second line ends with a \n. Does running unix2dos on that do a sensible thing on the first line? Compare it with my above recipe which appends DOSsy line at the end of the file.

Having said that, CRLF is unsafe for E-mail transfers anyway, so I think we would need a special option to tell git-apply that it should match '\n' that appears in the patch with '\r\n' in the file being patched. But I do not think that has anything to do with the breakage you saw in your reproduction recipe.

Do not open mailbox file as fopen(..., "rt")
as this strips CR characters from the diff,
thus breaking the patch context for changes
in CRLF files.

---

This reproduction scenario results in exactly the same problem. The problem is observed on Cygwin.
My initial evaluation of the problem turned out to be completely bogus.

I've tracked the problem down to the fopen(file, "rt") in mailsplit.c, which then truncates the CR character from the patch file. This changes the patch context lines and it no longer applies. Changing it to fopen(file, "r") fixes the problem.

My use case does not involve e-mail transfers at all. I'm using git-format-patch and git-am to rewrite the patch sequence with different commit messages.

Unfortunately, some of my fellow developers are not quite careful, and occasionally some of the source files acquire CR characters, sometimes in several lines only.

fd405a0843f3efd474bc7897b06d813d6498fbf4

 mailsplit.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

fd405a0843f3efd474bc7897b06d813d6498fbf4

index c529e2d..70a569c 100644
@@ -162,7 +162,7 @@ int main(int argc, const char **argv)
 
 	while (*argp) {
 		const char *file = *argp++;
-		FILE *f = !strcmp(file, "-") ? stdin : fopen(file, "rt");
+		FILE *f = !strcmp(file, "-") ? stdin : fopen(file, "r");
 		int file_done = 0;
 
 		if ( !f )

1.3.3.gfd40

Heh, I had a trailing CR after the "with capital letters." and one blank line between paragraphs, but I now see two blank lines there. So even in this modern day, preserving CRLF is not something that happens by default -- you would need to make sure that everybody on your mailpath to the recipient is set up the right way.

So now I am less in favor of the change than when I wrote that response.