{"thread":{"id":"33168","subject":"git-am and CRLF","startedAt":"2013-03-13T16:54:14Z","lastAt":"2013-03-13T17:46:12Z","messageCount":3,"participants":["Erik Faye-Lund","Brandon Casey"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"211230","messageId":"CABPQNSb9euNgCY9g617opThHC8OUpZQvJ+peor8Yk39LZ+y+TQ@mail.gmail.com","threadId":"33168","inReplyTo":null,"subject":"git-am and CRLF","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2013-03-13T16:54:14Z","receivedAt":"2013-03-13T16:54:14Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"I recently tried to apply a patch-series to a repo that is\nunfortunately full of CRLF files, and was a bit surprised that it\ndidn't work at all.\n\nSo I made a small repro-case, and it seems CRLF new-lines is indeed\nthe problem. Any clue how to fix it? The way I see it, we should\nsimply be able top treat the CR as any other character, and succeed.\nBut that doesn't seem to happen...\n\ngit init test &&\n(\n        cd test/ &&\n        git config core.autocrlf false &&\n        printf \"%s\\r\\n%s\\r\\n\" \"foo\" \"bar\" > test.txt &&\n        git add test.txt &&\n        git commit -m. &&\n        printf \"%s\\r\\n%s\\r\\n%s\\r\\n\" \"foo\" \"baz\" \"bar\" > test.txt &&\n        git commit -am. &&\n        git format-patch -1 &&\n        git reset --hard HEAD^ &&\n        git am 0001-.patch\n)\n"},{"id":"211234","messageId":"CA+sFfMfJp1-REXVjipUhsVrUKDSmhrBkV0yd_=sMwwmiw2aypQ@mail.gmail.com","threadId":"33168","inReplyTo":"CABPQNSb9euNgCY9g617opThHC8OUpZQvJ+peor8Yk39LZ+y+TQ@mail.gmail.com","subject":"Re: git-am and CRLF","fromName":"Brandon Casey","fromEmail":"drafnel@gmail.com","sentAt":"2013-03-13T17:42:42Z","receivedAt":"2013-03-13T17:42:42Z","isPatch":false,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"On Wed, Mar 13, 2013 at 9:54 AM, Erik Faye-Lund <kusmabite@gmail.com> wrote:\n> I recently tried to apply a patch-series to a repo that is\n> unfortunately full of CRLF files, and was a bit surprised that it\n> didn't work at all.\n>\n> So I made a small repro-case, and it seems CRLF new-lines is indeed\n> the problem. Any clue how to fix it? The way I see it, we should\n> simply be able top treat the CR as any other character, and succeed.\n> But that doesn't seem to happen...\n>\n> git init test &&\n> (\n>         cd test/ &&\n>         git config core.autocrlf false &&\n>         printf \"%s\\r\\n%s\\r\\n\" \"foo\" \"bar\" > test.txt &&\n>         git add test.txt &&\n>         git commit -m. &&\n>         printf \"%s\\r\\n%s\\r\\n%s\\r\\n\" \"foo\" \"baz\" \"bar\" > test.txt &&\n>         git commit -am. &&\n>         git format-patch -1 &&\n>         git reset --hard HEAD^ &&\n>         git am 0001-.patch\n> )\n\nDoes 'git am --keep-cr' help?\n\nUnfortunately the original information about line ending is lost once\na patch is sent via email since RFC2822/822 dictates that the line\nending in an email must be crlf.  So by default, mailsplit strips it.\n\n-Brandon\n"},{"id":"211236","messageId":"CABPQNSYi2UnpEBu_-Mb=2XvCodeoseTGPKCiSo0+2MrnHt3rZQ@mail.gmail.com","threadId":"33168","inReplyTo":"CA+sFfMfJp1-REXVjipUhsVrUKDSmhrBkV0yd_=sMwwmiw2aypQ@mail.gmail.com","subject":"Re: git-am and CRLF","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2013-03-13T17:46:12Z","receivedAt":"2013-03-13T17:46:12Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Wed, Mar 13, 2013 at 6:42 PM, Brandon Casey <drafnel@gmail.com> wrote:\n> On Wed, Mar 13, 2013 at 9:54 AM, Erik Faye-Lund <kusmabite@gmail.com> wrote:\n>> I recently tried to apply a patch-series to a repo that is\n>> unfortunately full of CRLF files, and was a bit surprised that it\n>> didn't work at all.\n>>\n>> So I made a small repro-case, and it seems CRLF new-lines is indeed\n>> the problem. Any clue how to fix it? The way I see it, we should\n>> simply be able top treat the CR as any other character, and succeed.\n>> But that doesn't seem to happen...\n>>\n>> git init test &&\n>> (\n>>         cd test/ &&\n>>         git config core.autocrlf false &&\n>>         printf \"%s\\r\\n%s\\r\\n\" \"foo\" \"bar\" > test.txt &&\n>>         git add test.txt &&\n>>         git commit -m. &&\n>>         printf \"%s\\r\\n%s\\r\\n%s\\r\\n\" \"foo\" \"baz\" \"bar\" > test.txt &&\n>>         git commit -am. &&\n>>         git format-patch -1 &&\n>>         git reset --hard HEAD^ &&\n>>         git am 0001-.patch\n>> )\n>\n> Does 'git am --keep-cr' help?\n>\n\nIt does, how silly of me not to try that before posting.\n\n> Unfortunately the original information about line ending is lost once\n> a patch is sent via email since RFC2822/822 dictates that the line\n> ending in an email must be crlf.  So by default, mailsplit strips it.\n\nHmpf. I didn't transport my patches over e-mail, I simply used\ngit-format-patch/git-am to transfer the patches from one git-svn clone\nto another. But since that's kind of an \"abuse\" of\ngit-format-patch/git-am, perhaps just using --keep-cr is the right\nthing.\n\nThanks anyway :)\n"}]}