Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set

On Tue, Jul 29, 2008 at 11:17:23PM +0200, Eyvind Bernhardsen wrote:

My point was that autocrlf penalises Windows users just as much as it  
does Linux users, so why should it be turned on by default on  
Windows? 

Because it does make sense on Windows (I mentioned some reasons for that
in my previous email), and it does NOT make any sense on Linux unless
you copy files from Windows.

quoted

And the main argument for having that in this way is that people  
with LF
text files should be unnecessary penalized for Windows being  
different.

I know, but my point is that I don't like to be unnecessarily  
penalised any more when I am using Windows than when I'm using Linux  
or OS X.

It seems you still have not realized that from the very day when you
started to use Windows, you are penalized for that day-in, day-out.
Let's take something simple. For instance, the hello-world program:
cat <<=== > hello.c
#include <stdio.h>
int main() {
	printf ("Hello world!\n");
	return 0;
}
===

You can compile it on Linux and Windows (using Microsoft Visual C).
Now, if you run it on Linux, it will print 13 symbols (exactly
as many as there are symbols in the printf string) while on Windows
you will get 14 bytes. It means that printf and as many other C
function on Windows does conversion and penalize you already!

I would like the default to be "no conversion", and for  
conversion to be enabled not based on platform, but as a policy  
decision on the repositories where it actually matters.

If Microsoft C library did not do any conversion, I suspect we would
have this CRLF conversion at all!

You can have anything you like in _your_ repository, of course, but if  
you're not publishing it anywhere, who cares what your line endings  
are?  Your line endings only matter when you publish. 

You can publish only what you have. So, it must decided before.

That's why I  
want a setting that is propagated: so that when you clone a repository  
with a LF-only policy, Git knows what to do.

LF-only policy is the only sane policy for any text files. It has nothing
to do with clone.

I think the real penalty is that with autocrlf enabled, Git no longer  
stores exactly what I committed.

And what is wrong with that? In any case, Git deltifies and compress
your files. Why does it not bother you? So, what matters here is
whether you are able to get back exactly what you put or not. That's
why Git has this safecrlf option! Of course, it is guarantee to get
exactly the same back only if you have the same autocrlf setting,
but if you have different autocrlf settings, it means that you want
*different* representation of text files!

quoted

Files that do not need conversion (such as *.bat) should be marked as
"-crlf" in .gitattributes.

Yes, and I see you checked that "crlf=input" does actually work when  
you want LF-only, sorry about that.  The syntax is _horrible_, though.

quoted

Of course, those who are very careful and have good editors can set
autocrlf=false even on Windows...

Right, or who know that the repository they're using will only be  
shared with other Windows users.

WRONG! Using storing CRLF in text files is a completely idiotic idea.
Those who do so asked for troubles, so they should not complain!

Internally, Git doesn't really care, does it?

It DOES!!! Such things like merges and diffs and many other every day
commands do care about end-of-lines and the ONLY end-of-line they
recognize is '\n'. In fact, there are more than 400 places in Git where
'\n' is used. Of course, not all of them may be qualified as internals
but many of them do.

So, as long as Git internally consider only LF as the end-of-line.

Heh.  Where I work, we hacked CVS for Windows to get away from that  
behaviour :)

Maybe, you used Cygwin version of CVS, which had LF, but those Windows
versions of CVS I used produced CRLF on Windows.

quoted

The problem is how to determine when it is necessary and when it is
not. If I never commit with wrong EOLs, I don't think it is necessary
for me to have this conversion... On the other hand, I don't mind  
having
this check as default.  It does not really bother me much, and if I  
can
turn it off, it is fine with me. But I suppose other people may feel
differently about this issue.

Well, what I want is to be able to say "it is necessary to do eol  
conversion in this repository",

You always can do that in _your_ repository:
git config core.autocrlf ...

allowing the default to be "don't do  
eol conversion" on Windows, too.  For a setting like that to be  
useful, it has to be propagated when the repository is cloned.

Why? Other people may have other preferences.

I want it to be versioned because you might want to change it without  
messing with the content that's already in the repository.  This is  
actually my main motivation, since I have lots of CRLF-infused CVS  
history to deal with.

Well, you can try to use .gitattributes, but I believe it would be far
more reasonable to clean this mess with line-ending than finding a
way to continue insanity with different ending in different text files.

It should apply on Linux as well as Windows because there is always  
the chance that a user will manage to commit a CRLF on Linux (a  
colleague of mine once complained that CVS on Linux doesn't do eol  
conversion; he edited files on Windows, but checked them in on  
Linux).

For those who need it, Git provides autocrlf=input. But the question
here is what should be default. I don't think that those who copies
files directly from Windows to Linux are majority. OTOH, I don't
mind autocrlf=input as default. If it can be turned off, it is fine
with me :)

It would probably be okay to have a setting that turns all  
conversion off, but wouldn't that be kind of rude?

How so?


Dmitry