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

Salikh Zakirov [off-list ref] writes:

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.

I do not think that is the case.

Is this a bug or known deficiency?

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

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

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

---

Junio C Hamano wrote:

	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

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.

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.

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

diff --git mailsplit.c mailsplit.c
index c529e2d..70a569c 100644
--- mailsplit.c
+++ mailsplit.c

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