Thread (58 messages) 58 messages, 11 authors, 2016-06-15

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

flat view

From: Avery Pennarun <hidden>
Date: 2016-06-15 22:48:46

On Fri, May 7, 2010 at 11:31 PM, Robert Buck [off-list ref] wrote:
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:
quoted
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.
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help