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