On 30. juli. 2008, at 23.45, Dmitry Potapov wrote:
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.
It doesn't make any more sense on Windows than it does on Linux,
unless the user is careless about CRLFs and the repository will be
shared with Linux users. If you have to work with undisciplined
Windows users but don't actually use Windows yourself, it might _seem_
to make sense, but that is an illusion.
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!
But I don't use printf to store files. What does printf have to do
with anything?
Btw, I'm not actually a "natural" Windows user; I have a Mac on my
desktop, and I prefer Linux to Windows on my own PCs. I often use
Windows at work, though, and I'm trying to make Git work as well as
possible when I do.
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!
Surely, but unfortunately, I don't live in happy fairy land.
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.
Yes! Someone should decide that the repository should only have LFs
in it, then flag it as such so that Git can respect that decision.
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.
Gah! So close, but so far. What about a repository which already has
CRLFs in it? You're telling me that it shouldn't have CRLFs in it,
which is almost entirely unhelpful.
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!
My point is that if I commit two files with different line endings, I
want Git to store them that way. Works on Linux by default, doesn't
work on Windows by default. Deltification and compression are
irrelevant since they don't change the content. autocrlf does.
You only want to normalise text files if you (a) have undisciplined
committers, and (b) need to share the repository between Windows and
Unix. Right now, the default configuration of Git assumes that all
Windows users are undisciplined, and that they will always be sharing
repositories with Unix users.
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!
But some text files need CRLFs, the autocrlf mechanism even caters for
them. And it's not like the extra CR actually hurts anything; I use
Git on Windows with "autocrlf=false", and I've yet to see any problems
with it. The reason I've changed from the default "autocrlf=true" is
that I've seen plenty of problems with that.
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.
Buh? That's crazy talk. The only time CRLFs cause trouble with git
is when autocrlf is enabled. Try this:
git init
echo -n "testing\r\ntesting 2\r\n" > testing
git add testing
git commit
git config --bool --add core.autocrlf true
touch testing
git diff
File with CRLF in the repository, file with CRLF in the working
directory, so where does the difference come from? The same thing
happens with "autocrlf=input", and the problem is obviously a lot
bigger when you're trying to merge.
Now I've shown you when autocrlf is a problem, you show me a case
where CRLFs cause trouble with autocrlf=false.
So, as long as Git internally consider only LF as the end-of-line.
Bah. To the extent it "cares", Git just sees CR as an extra white
space character before the end-of-line LF, and you know it.
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.
No, we just compiled our own, precisely because we didn't want CVS to
mangle our data, even on Windows. The CVS repositories are used by
Linux and Windows clients, and some developers had their working
directories on cross-platform network shares, so eol conversion just
caused unnecessary problems.
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 ...
I can, except that (a) any CRLFs already in the repository will cause
trouble, and (b) everyone who clones from me has to make the same
setting manually, or they won't follow the same convention.
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.
Yes. Other people may have other preferences which will lead them to
push CRLFs to my repository. That is why the setting should be
propagated.
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.
But I'd rather not change the historical data in every repository. So
yes, I think it's a good idea to clean up the line endings, but I
would like to do it in a way that allows me to check out an old
version with mixed line endings while still ensuring that newly
committed files are normalised.
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 :)
Yeah, if autocrlf is set, it probably makes sense to use it, i.e.
anyone who doesn't want line ending conversion at all can set
"autocrlf=false".
It would probably be okay to have a setting that turns all
conversion off, but wouldn't that be kind of rude?
How so?
You're explicitly saying "I don't care if I commit CRLFs into a
repository that requests only LFs". So you're probably only saying it
because you know you won't commit CRLFs anyway, but since the cost is
so low, why not make sure?
--
Eyvind Bernhardsen
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
