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

On Sun, Aug 03, 2008 at 11:54:34AM -0700, Tarmigan wrote:

I guess so... Because for me it is very important that most of files I store are text files. In fact, such operations as diff and merge would not make much sense for binary files, would they? IOW, Git is a revision control system, not a versioning file system.

Sure, git trusts you. You can always turn off some features if you don't like them; but the issue having the right defaults. autocrlf=true is the right default if you want to have CRLF in your work directory. And as long as text heuristic is right (and it works pretty damn good), you get exactly what you put in it. In very very rare cases where the heuristic is wrong, it will warn you about that you are not going to have back what you put. So, you can tell Git explicitly that you want this file stored as binary. But this situation is very unlikely unless you store in it something like svndump files, but storying such files in not the main purpose of Git.

So, I don't think that this CRLF conversion is a real issue, except that the fact that changing the global autocrlf value should not have changed autocrlf in already existing repositories. Because autocrlf is not just a preference, but also determines in what format your files in the working directory are stored. So, I believe it should be corrected. But even in this case, you do not really lose anything.

And not by default? Currently, does not support encoding filenames from your local encoding to UTF-8. And that will be a problem at some point if you store file names in non UTF-8 encoding. But it is a separate issue connected to i18n support. I don't think it makes sense to go into it right now as it is completely irrelevant to the problem we discuss.

What is relevant is that Git *does* change filename representation. For instance, if you try to add a file with a name 'foo\bar', Git will actually add 'foo/bar'. You see, on check-in, Git converts the directory separator from its Windows form ('\') to the format it uses internally ('/').

So, it is logical to do the same text files, because text files are sequences of lines separated by line-separator, which is CRLF on Windows, but its internal representation in Git is LF.

Because keyword expansion is almost always meaningless thing to do in your working directory. It just makes things slower and you do not win *anything*. Arguably, there are some cases when you may want some expansion during export your sources to archive, but even that is very uncommon.

Change case? Would it not be a completely insane thing to do? People put some meaning in what registry of letters when wrote names, why would you want Git (or any source control system) to mess up with that?

It does not change the content, it changes the EOL marker from its external to internal representation. It does the same thing as what C library on Windows does when you read or write files in the text mode. This should be completely transparent to users as long as autocrlf is not changed.

Dmitry