threads / discuss / 33168

git-am and CRLF

Subject: git-am and CRLF

## tl;dr

3 messages between Mar 13, 2013 and Mar 13, 2013.

replies: 2people: 2as markdown or json

Erik Faye-Lund· Mar 13, 2013, 16:54 UTC · lore

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· Mar 13, 2013, 17:42 UTC · re: Erik Faye-Lund · lore

Re: git-am and CRLF

On Wed, Mar 13, 2013 at 9:54 AM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
Show 22 quoted lines
> 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· Mar 13, 2013, 17:46 UTC · re: Brandon Casey · lore

Re: git-am and CRLF

On Wed, Mar 13, 2013 at 6:42 PM, Brandon Casey <drafnel@gmail.com> wrote:
Show 26 quoted lines
> On Wed, Mar 13, 2013 at 9:54 AM, Erik Faye-Lund <kusmabite@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 :)

← back to recent threads