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

[Dmitry Potapov <dpotapov@gmail.com>]

On Fri, May 07, 2010 at 02:54:40PM -0700, Linus Torvalds wrote:
> 
>  (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