On 29. juli. 2008, at 15.46, Dmitry Potapov wrote:
On Fri, Jul 25, 2008 at 11:05:33PM +0200, Eyvind Bernhardsen wrote:
You clearly want *enforcing* and versioning for you is just means to
do
that. Regardless, what is the best way to achieve that, the *main*
question is whether we want this enforcing and if yet then in what
form
and to what degree...
The versioning has nothing to do with the enforcing per se, it just
makes it possible to convert a repository with CRLFs to one that's LF-
only without having to rewrite history. See below.
If we had core.autocrlf=input as default then clueless users will
not
checkin files with the incorrect ending. But there is an objection
to
that -- you penalize those who always have good endings. And even
the
fact that is merely default value that you can easily change to
false
does not convince everyone.
That is an excellent argument for why setting "autocrlf=true" by
default on Windows was a bad idea. Thanks! :)
I am sorry, but I don't see connection here.
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? But I've promised not to complain any more about this until
I have cold, hard code to back me up.
Again, why should people who do not use Windows and other CR-damaged
tools be penalized? No one can prevent me from putting in *my* own
repository whatever I want anyway. Thus, if we agreed having this
conversion/check is useful, remaining questions are:
1. whether this check should be possible to turn off
2. whether this check should be turned off by default for people
who use Git on other system than Windows?
The current status is:
1. Yes, it is possible to turn of this conversion
2. It is turned off by default for anyone but MSYS/GIT users.
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. 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.
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. 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.
As you say, the reason I want the setting to be per-repository is
that
I don't think the cost is worthwhile for every repository.
Side note: Personally, I am not very concerned about this cost, but
some
people are...
Yeah :)
I think the real penalty is that with autocrlf enabled, Git no longer
stores exactly what I committed.
The case
where it _is_ worthwhile is when the repository will be shared
between
Windows users and Linux users, and the Windows users want CRLFs in
their working directories. I think it's worthwhile to actually make
Git work right in that case.
Windows users who want CRLF should set autocrlf=true
Windows users who prefer LF should set autocrlf=input
Non-Windows users who copy file directly from Windows should also
set autocrlf=input
All other users who do not touch Windows may have autocrlf=false.
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. But with "autocrlf=false" in their
config, they would have to remember to set "autocrlf=true" in .git/
config in any new repositories they want to share with Linux users.
I'd like to make that per-repository configuration automatic.
As a side note, there's a lot of complaining about the cost of
enforcing LF-only input, but I can't remember seeing any actual
numbers. Is it really that bad?
No, it is not bad. In most practical cases, you will not notice any
difference. I've posted some numbers in this thread. You can find
them here:
http://article.gmane.org/gmane.comp.version-control.git/89908
Oh, thanks! I missed that post, and I agree that those numbers don't
look particularly worrying.
[...]
but there are people who do not want to pay any price for
conversion.
Currently, "core.autocrlf=false" means to do nothing about end-of-
lines,
and even to ignore setting in .gitattributes. Should it be
possible to
disable *any* conversion on checkin and checkout? Should this be
that
value be the default, which most users use?
Well, there's no reason why Git repositories used only on Windows
machines shouldn't store CRLFs, so why should all msysgit users pay
the cost on every checkin _and_ checkout?
1. You may want to use on other platforms later. In any case, it makes
much sense to have the default that compatible with other systems.
This is why I want the setting to be versioned. If you decide to
share with other platforms later, you just enable the setting and "git
commit -a" (untested! Recursive touching is probably required
first). No history has to be rewritten, and new checkouts will work
properly (as will old checkouts, but for a slightly different value of
"properly").
2. Conversion cost is not significant (I suppose much less than gzip
compression used for all objects) and it also saves some space.
3. Internally, Git considers only LF as true end of line. CR is just
like an extra space before end-of-line. Is any good reason to have
it inside of your repo anyway?
Internally, Git doesn't really care, does it? The only reason to keep
the line endings I committed is "because that's what I committed", but
I think it's quite a good reason.
4. This is what other VCSes do on Windows. CVS converts all text files
on checkin. SVN does the same for files having svn:eol-style=native.
Heh. Where I work, we hacked CVS for Windows to get away from that
behaviour :)
In fact, if you read the discussion we had here some time ago, you may
find some other arguments too.
Yep, but I think I'm doing this backwards. Instead of rehashing old
arguments, I need to implement something that does what I want and let
the list decide if it's useful or not.
This is the reason the setting needs to be a per-repository policy
and
not a user configuration;
What exactly?
users should not be able to configure away
correctness,
Why not? *Every* user has him/her own repository, so he/she can do
*anything* with it, in principle.
but they shouldn't be penalised unnecessarily for it,
either.
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", 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.
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.
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). It would probably be okay to have a setting that turns all
conversion off, but wouldn't that be kind of rude?
Thanks, all, for your help in getting my ideas straight; now to find
out if I'm coder enough to implement them. If not, I'll just stick
with setting "autocrlf=false" on Windows and stop whining.
--
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
