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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, May 7, 2010 at 11:31 PM, Robert Buck <buck.robert.j@xxxxxxxxx> 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:
>> 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
--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]