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

From: Dmitry Potapov <dpotapov@gmail.com>
Date: May 8, 2010, 20:49 UTC
Message-ID: <20100508204934.GA25566@dpotapov.dyndns.org>
In-Reply-To: <alpine.LFD.2.00.1005071441341.901@i5.linux-foundation.org>

On Fri, May 07, 2010 at 02:54:40PM -0700, Linus Torvalds wrote:

Show 24 quoted lines

> 
>  (a) you should try to avoid do things like that in the first place. For 
>      something like an attribute file, you should just list the files you 
>      want to convert. That's the _point_ of an attribute. So it's much 
>      nicer if you instead actually are explicit about it, ie
> 
> 	*.[ch] crlf
> 	*.txt crlf
> 	*.jpg -crlf
> 
>      should be the _primary_ way you do it, since the autocrlf thing is a 
>      bit dangerous in theory.
> 
>  (b) But let's say that you want to do it anyway (because you're lazy 
>      and because autocrlf works pretty damn well in practice), isn't that 
>      a really ugly and crazy thing to add _another_ attribute name for 
>      that?
> 
>      IOW, if you really want to say "do automatic crlf for this set of 
>      paths", the natural syntax for that would be
> 
> 	* crlf=auto
> 
>      No? Not some totally new attribute name.

I like your proposal and it makes perfect sense to me, but I am not new to git and core.autocrlf. I have observed that many people who were new to Git often got confused by meaning of the crlf attribute. In essence, at first, they thought that it means what you would probably describe as crlf=force. Thus, seeing something like this:

    *.sln -crlf

baffled them, because sln files have CRLF as ending. So, it was very counter-intuitive for them. Of course, you can explain that Git stores text files with LF internally, and why it is the sane thing to do, and why sln files are not exactly text files (at least, non-text in sense of eol-conversion), etc... but I believe that all those discussion and explanation could be easily avoided by renaming 'crlf' as 'eol'. Now, if you look at this:

      *.sln -eol
      *.jpg -eol
      *.txt eol
      *.[ch] eol

it is clear that .sln and .jpg files are stored "as is", while Git does the end-of-line conversion for others files in accordance with user's preference. Why should users bother at all how Git stores text files internally? They do not need to know that Git stores text files with LF internally. They just want to checkout those files with the right ending for their platform.

So, perhaps, 'eol' would be a better name than 'crlf' for new Git users.

Dmitry