Re: git am and CRLF files
- From
Erik Faye-Lund <kusmabite@googlemail.com>
- Date
- Nov 16, 2009, 11:43 UTC
- 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 <nanako3@lavabit.com> wrote:
Show 19 quoted lines
> Quoting Stefan Naewe <stefan.naewe@atlas-elektronik.com> > >>> 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