From: Erik Faye-Lund Date: Mon, 16 Nov 2009 11:43:36 GMT Subject: Re: git am and CRLF files Message-ID: <40aa078e0911160343k41393197s56d26576bcbfbe90@mail.gmail.com> In-Reply-To: <20091116195036.6117@nanako3.lavabit.com> On Mon, Nov 16, 2009 at 11:50 AM, Nanako Shiraishi wrote: > Quoting Stefan Naewe > >>> A repository with some UNIX (LF) and some Windows (CRLF) files. >>> (and no: I will not change the files. My editors handle CRLF and LF correctly) >>> >>> My problem: >>> >>> 'git am' can't handle changes in CRLF files because the patch >>> gets converted (by git mailsplit) to contain only LF. >> >>> Stefan >> >> Does anyone have any comment on this ? > > This was done very much on purpose. > > The "am" command is meant to handle e-mailed patches, and traditionally > mails are known to clobber carriage returns. > According to RFC 5322, email messages use CRLF as the newline-sequence. In order to be able to distinguish between CRLF and LF in an e-mail patch, the message needs to be use some transfer-encoding that preserves newline style (like base64). Perhaps this would be better fixed by having format-patch (or prehaps the MUA ?) base64-encode the message body if the file contains non-LF-newlines, and normalizing CRLF to LF before transport-decoding? Or does some MUAs transport-decode before storing the message to disk? I realize this might make it a bit tricky to review patches that contains CRLF-newlines before mailing them out, but perhaps inspecting the format-patch output is the wrong place to do this? -- Erik "kusma" Faye-Lund