On Wed, Mar 13, 2013 at 9:54 AM, Erik Faye-Lund <kusmabite@xxxxxxxxx> wrote: > I recently tried to apply a patch-series to a repo that is > unfortunately full of CRLF files, and was a bit surprised that it > didn't work at all. > > So I made a small repro-case, and it seems CRLF new-lines is indeed > the problem. Any clue how to fix it? The way I see it, we should > simply be able top treat the CR as any other character, and succeed. > But that doesn't seem to happen... > > git init test && > ( > cd test/ && > git config core.autocrlf false && > printf "%s\r\n%s\r\n" "foo" "bar" > test.txt && > git add test.txt && > git commit -m. && > printf "%s\r\n%s\r\n%s\r\n" "foo" "baz" "bar" > test.txt && > git commit -am. && > git format-patch -1 && > git reset --hard HEAD^ && > git am 0001-.patch > ) Does 'git am --keep-cr' help? Unfortunately the original information about line ending is lost once a patch is sent via email since RFC2822/822 dictates that the line ending in an email must be crlf. So by default, mailsplit strips it. -Brandon -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html