Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization

From: Avery Pennarun <apenwarr@gmail.com>
Date: May 8, 2010, 03:45 UTC
Message-ID: <k2q32541b131005072045jc1192392ke234b7b543aaca33@mail.gmail.com>
In-Reply-To: <AANLkTikbIHfX5pUOn2Yk44IWzqTFDpyapC1V-C-br9jF@mail.gmail.com>

On Fri, May 7, 2010 at 11:31 PM, Robert Buck <buck.robert.j@gmail.com> wrote:

Show 12 quoted lines

> Actually, Linus, that depends. And while you will recognize this, let
> me state the obvious, that there are cases where for certain text
> files the platform does not matter, that for all platforms they MUST
> normalize to one setting. For instance there are cases where text
> files MUST be LF ended on ALL platforms. Have you considered XML to be
> one such example? The W3 XML spec states:
>
>   ... [XML processors] MUST behave as if it normalized all line
> breaks in external parsed entities (including the document entity) on
> input, before parsing, by translating both the two-character sequence
> #xD #xA and any #xD that is not followed by #xA to a single #xA
> character.

Erm, this seems to be a counterexample to your point. It says very clearly that the files can use either LF or CRLF line endings, and will be parsed correctly either way, or your parser is broken. So pretty much any CRLF conversion rule (or none at all) will work with such files.

Hasen wrote:

>> The way git handles crlf is just confusing; in fact it's so confusing
>> that it's often better to just turn it off.

True. This discussion is about fixing that, though, so it seems unnecessary to make that point.

> Hasen makes a good point here. It is simply this, the LF issue does
> not boil down to a single boolean switch. People who think of the
> LF/CRLF issue as a boolean switch are not dealing with all the facts.
> There's a lot of grey, not simply black and white.

How on earth is anyone suggesting that it's a simple boolean switch? Linus posted an 8-cell truth table earlier, and he hadn't even included all the cases.

Show 6 quoted lines

> I'd generally say,
>
> * perform conversions, or no conversions as the case may be, on the
> obvious file types
> * when conversions occur, normalize internally to only one convention
> * otherwise perform no conversions

Unfortunately those steps aren't clear enough to be helpful. "as the case may be" and "obvious file types" are definitely not obvious, or we wouldn't be here.

> Confusion, yes. The Git documentation is very confusing on this
> point... Linus and Junio may want to lift a page from the Perforce
> book ;)

I've learned that git people never learn from anyone's book. svn has also had this problem solved pretty much forever, and would be easy to copy. For better or for worse, it all has to be hashed out from scratch or it won't happen.

> It would seem to me there are some text files that by convention MUST
> have LF regardless of the platform, and there are examples of text
> files that MAY have CRLF depending upon the platform.

Well... obviously. The former case is crlf=false; the latter is crlf=true. To bring up my point again about the confusing configuration options, you might think that "crlf=true" means "always CRLF", but in fact that's not the case. In fact it works the way you want.

Have fun,

Avery