# git-am and CRLF 3 messages from 2013-03-13 to 2013-03-13. Participants: Erik Faye-Lund, Brandon Casey. Thread: https://gitlist.dev/t/33168 ## Erik Faye-Lund, 2013-03-13 16:54 Subject: git-am and CRLF Message-ID: URL: https://gitlist.dev/e/CABPQNSb9euNgCY9g617opThHC8OUpZQvJ%2Bpeor8Yk39LZ%2By%2BTQ%40mail.gmail.com ``` 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 ) ``` ## Brandon Casey, 2013-03-13 17:42 Subject: Re: git-am and CRLF Message-ID: URL: https://gitlist.dev/e/CA%2BsFfMfJp1-REXVjipUhsVrUKDSmhrBkV0yd_%3DsMwwmiw2aypQ%40mail.gmail.com In-Reply-To: ``` On Wed, Mar 13, 2013 at 9:54 AM, Erik Faye-Lund 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 ``` ## Erik Faye-Lund, 2013-03-13 17:46 Subject: Re: git-am and CRLF Message-ID: URL: https://gitlist.dev/e/CABPQNSYi2UnpEBu_-Mb%3D2XvCodeoseTGPKCiSo0%2B2MrnHt3rZQ%40mail.gmail.com In-Reply-To: ``` On Wed, Mar 13, 2013 at 6:42 PM, Brandon Casey wrote: > On Wed, Mar 13, 2013 at 9:54 AM, Erik Faye-Lund 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? > It does, how silly of me not to try that before posting. > 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. Hmpf. I didn't transport my patches over e-mail, I simply used git-format-patch/git-am to transfer the patches from one git-svn clone to another. But since that's kind of an "abuse" of git-format-patch/git-am, perhaps just using --keep-cr is the right thing. Thanks anyway :) ```