git-am and CRLF
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 ) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-am and CRLF
On Wed, Mar 13, 2013 at 9:54 AM, Erik Faye-Lund kusmab...@gmail.com 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-am and CRLF
On Wed, Mar 13, 2013 at 6:42 PM, Brandon Casey draf...@gmail.com wrote: On Wed, Mar 13, 2013 at 9:54 AM, Erik Faye-Lund kusmab...@gmail.com 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 :) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
