Thread (3 messages) flat view 3 messages, 3 authors, 2016-06-15

Re: [RFR] gitattributes(5) documentation

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: 2016-06-15 22:43:06

Great. And reading the documentation, something struck me: wonderful docs 
about crlf, but it became clear that either the docs are wrong, or the 
behaviour is less than optimal: you cannot specify "crlf=input" any way?

So I would sugegst that
 - if crlf is set, we still honor the value of "core.autocrlf", we just 
   don't care about the *content*.

Maybe that's what the code is doing (I thought it did, but I'm too lazy to 
check), but the docs don't say that:

On Thu, 19 Apr 2007, Junio C Hamano wrote:
Set::
	A path to which the `crlf` attribute is set is converted
	to have CRLF line endings in the working tree upon
	checkout, and converted back to strip CRLF line endings
	to LF line endings upon checkin.
This documented behaviour is non-optimal for a few reasons:
 - it makes it impossible to say "this is text", and have it work on UNIX 
   platforms ;)
 - it makes it impossible to have "autocrlf=input", and then correct one 
   single file that was incorrectly guessed to be binary, and have that 
   file behave like other files.

So I _think_ the right rules are:

 - unspecified: use autocrlf *and* content detection logic
 - unset: never do crlf<->lf ("binary")
 - set: use autocrlf without content detection logic ("text")

with possibly an added rule:

 - set to value: "true" or "input" force that particular setting 
   *regardless* of autocrlf, ie we'd always get CRLF even on UNIX.

Hmm?

			Linus
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help