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
---------

Salikh Zakirov <Salikh.Zakirov@Intel.com> writes:

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.

Signed-off-by: Salikh Zakirov <Salikh.Zakirov@Intel.com>

---

Junio C Hamano wrote:

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

Salikh Zakirov <Salikh.Zakirov@Intel.com> writes:

I personally think this is a right change. Provided if MTAs on the path between patch originator and you are not broken and your MUA saved the message with CR/LF distinction in the contents intact, this should do more right thing.

I see broken patches every once in a while, but when they are mangled by the mailpath, CRLF is the least of the problem; they have other whitespace breakage that makes them unapplicable anyway.

Having said that, however, that historically used to be a big IF with capital letters.

I have a feeling that Linus did this on purpose. For the projects we originally cared about, a patch to introduce CRLF in the tracked content was a broken patch 100% of the time (not 99%), and most likely caused by a breakage somewhere on the mailpath. At least in the original git context, protecting UNIX/POSIX people from broken MTA/MUA counted far more than catering to people who deals with DOSsy contents.

So I am slightly in favor of the change, but just barely.

Junio C Hamano <junkio@cox.net> writes:

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.