From: Avery Pennarun <apenwarr@gmail.com>
To: Robert Buck <buck.robert.j@gmail.com>
Cc: git@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>,
Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com>,
Junio C Hamano <gitster@pobox.com>,
kusmabite@googlemail.com, prohaska@zib.de
Subject: Re: [PATCH/RFC 0/3] Per-repository end-of-line normalization
Date: Fri, 7 May 2010 23:45:39 -0400 [thread overview]
Message-ID: <k2q32541b131005072045jc1192392ke234b7b543aaca33@mail.gmail.com> (raw)
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:
> 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
next prev parent reply other threads:[~2010-05-08 3:54 UTC|newest]
Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-05 10:01 What should be the CRLF policy when win + Linux? mat
2010-05-05 13:27 ` Ramkumar Ramachandra
2010-05-06 9:27 ` mat
2010-05-06 10:03 ` Erik Faye-Lund
2010-05-06 2:35 ` hasen j
2010-05-06 7:29 ` Wilbert van Dolleweerd
2010-05-06 15:34 ` hasen j
2010-05-06 17:15 ` Linus Torvalds
2010-05-06 17:26 ` Erik Faye-Lund
2010-05-06 20:00 ` hasen j
2010-05-06 20:23 ` Linus Torvalds
2010-05-06 20:40 ` Erik Faye-Lund
2010-05-06 22:14 ` hasen j
2010-05-06 23:25 ` Erik Faye-Lund
2010-05-18 15:13 ` Anthony W. Youngman
2010-05-06 22:27 ` [PATCH/RFC 0/3] Per-repository end-of-line normalization Eyvind Bernhardsen
2010-05-06 22:27 ` [PATCH/RFC 1/3] Add "auto-eol" attribute and "core.eolStyle" config variable Eyvind Bernhardsen
2010-05-06 22:27 ` [PATCH/RFC 2/3] Add tests for per-repository eol normalization Eyvind Bernhardsen
2010-05-06 22:27 ` [PATCH/RFC 3/3] Add " Eyvind Bernhardsen
2010-05-06 23:38 ` [PATCH/RFC 0/3] Per-repository end-of-line normalization Avery Pennarun
2010-05-06 23:54 ` Avery Pennarun
2010-05-07 8:45 ` Erik Faye-Lund
2010-05-07 16:33 ` Junio C Hamano
2010-05-07 16:57 ` Avery Pennarun
2010-05-07 17:10 ` Linus Torvalds
2010-05-07 19:02 ` Linus Torvalds
2010-05-07 19:11 ` Avery Pennarun
2010-05-07 19:16 ` Linus Torvalds
2010-05-07 19:35 ` Avery Pennarun
2010-05-07 19:45 ` Linus Torvalds
2010-05-07 19:58 ` Avery Pennarun
2010-05-07 20:06 ` Linus Torvalds
2010-05-07 20:17 ` Linus Torvalds
2010-05-07 20:42 ` Eyvind Bernhardsen
2010-05-07 20:57 ` Linus Torvalds
2010-05-07 21:17 ` Eyvind Bernhardsen
2010-05-07 21:23 ` Linus Torvalds
2010-05-07 21:30 ` Avery Pennarun
2010-05-07 21:37 ` Eyvind Bernhardsen
2010-05-07 21:58 ` Linus Torvalds
2010-05-07 21:54 ` Linus Torvalds
2010-05-07 22:14 ` Linus Torvalds
2010-05-07 22:34 ` Avery Pennarun
2010-05-07 22:54 ` hasen j
2010-05-07 23:18 ` Linus Torvalds
2010-05-07 23:47 ` hasen j
2010-05-07 23:50 ` Linus Torvalds
2010-05-08 0:19 ` hasen j
2010-05-08 0:33 ` Linus Torvalds
2010-05-08 1:39 ` hasen j
2010-05-08 1:49 ` Linus Torvalds
2010-05-08 2:49 ` hasen j
2010-05-08 3:31 ` Robert Buck
2010-05-08 3:45 ` Avery Pennarun [this message]
2010-05-08 10:36 ` hasen j
2010-05-08 11:36 ` Robert Buck
2010-05-08 3:34 ` Avery Pennarun
2010-05-08 0:31 ` Avery Pennarun
2010-05-07 22:19 ` Avery Pennarun
2010-05-08 20:49 ` Dmitry Potapov
2010-05-08 21:54 ` Linus Torvalds
2010-05-08 23:42 ` Dmitry Potapov
2010-05-09 7:49 ` Eyvind Bernhardsen
2010-05-09 10:35 ` Robert Buck
2010-05-07 20:58 ` Avery Pennarun
2010-05-07 19:23 ` Eyvind Bernhardsen
2010-05-07 19:31 ` Nicolas Pitre
2010-05-07 19:36 ` Avery Pennarun
2010-05-07 20:29 ` Nicolas Pitre
2010-05-07 21:00 ` Avery Pennarun
2010-05-07 21:12 ` Nicolas Pitre
2010-05-07 21:26 ` Avery Pennarun
2010-05-07 22:09 ` A Large Angry SCM
2010-05-07 22:10 ` Avery Pennarun
2010-05-07 19:40 ` Linus Torvalds
2010-05-07 20:32 ` Nicolas Pitre
2010-05-07 19:06 ` Junio C Hamano
2010-05-07 19:25 ` Eyvind Bernhardsen
2010-05-07 19:41 ` Finn Arne Gangstad
2010-05-07 20:06 ` Avery Pennarun
2010-05-07 20:11 ` Eyvind Bernhardsen
2010-05-07 7:15 ` What should be the CRLF policy when win + Linux? Gelonida
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=k2q32541b131005072045jc1192392ke234b7b543aaca33@mail.gmail.com \
--to=apenwarr@gmail.com \
--cc=buck.robert.j@gmail.com \
--cc=eyvind.bernhardsen@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=kusmabite@googlemail.com \
--cc=prohaska@zib.de \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).