On Dec 14, 2009, at 12:55 PM, Björn Steinbrink wrote:
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@xxxxxx> 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.
Sure, it won't affect LFers at all if you test the header lines of the
patch file - we'll be immune from that conversion then. Works for me :)
Thanks again,
Jason
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html