Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
- From
Dmitry Potapov <dpotapov@gmail.com>
- Date
- Jul 30, 2008, 21:45 UTC
- Message-ID
- <20080730214521.GC7008@dpotapov.dyndns.org>
- In-Reply-To
- <A8BF9951-AB9D-4391-A6CB-E9778064F4A8@orakel.ntnu.no>
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.
Show 9 quoted lines
> > > >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!
Show 11 quoted lines
> >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. > > >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.
Show 12 quoted lines
> > > >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.
Show 6 quoted lines
> > 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