Re: am fails to apply patches for files with CRLF lineendings

> On 2009.12.14 12:38:30 -0800, Jason King wrote:
>> On Dec 14, 2009, at 12:27 PM, Junio C Hamano wrote:
>>
>>> Björn Steinbrink <B.Steinbrink@gmx.de> writes:
>>>
>>>> Commit c2ca1d7 "Allow mailsplit ... to handle mails with CRLF
>>>> line-endings"
>>>> seems to be responsible.
>>>
>>> Yes, that commit is not only responsible but was deliberate.  For
>>> a better
>>> backstory, see:
>>>
>>> http://thread.gmane.org/gmane.comp.version-control.git/124718/focus=124721
>>>
>>> You'd notice that I was one of the people who didn't want to have  
>>> this
>>> change, so you don't need to convince _me_ that this was not a
>>> change to
>>> keep everybody happy, but you'd need to try a better job than I
>>> did back
>>> then to convince people who thought that "am" should directly work  
>>> on
>>> "Thunderbird saved mails" that what they want was a bad idea X-<.
>>
>> I dunno Junio, the back story doesn't really seem like a convincing
>> argument for totally breaking am's handling of real CRLFs.  Right
>> now, it seems to be a very bad thing that git can create a patch
>> that it can't apply.  The default am should always be able to apply
>> whatever format-patch has generated.
>>
>> If it's desirable to have am translate CRLFs to LFs, then why not
>> provide this as an option to am so as not to break merging of real
>> CRLF patches?  Eg.:
>>
>>  git am --convert-crlf
>
> Hm, currently it checks everyline. I didn't really think this through,
> but wouldn't it makes sense to have a per-mail flag, that checks just
> the first line, and if that has CRLF, then enable the dropping (unless
> --keep-cr is given), otherwise, keep things verbatim. That should (I
> think) make things work with non-messed up patches regardless of the
> files being patch, as well as with messed up patches as long as they
> don't try to patch files with CRLF line-endings.