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

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Eyvind Bernhardsen
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 [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

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

Dmitry Potapov
On Sat, Aug 02, 2008 at 02:51:28PM +0200, Eyvind Bernhardsen wrote:

> 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.

It does, because LF is the only EOL that Git recognize internally,
and if CRLF sometimes works, but it is an artifact. With the same
success you can rely on a value of uninitialized variable or any
other kind of undefined behavior.

> 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.

Illusion? Is the most logical objection that you capable to produce
to all my explanation? I think it is very convenient approach, but
shall we follow it a bit further and declare all your problem with
line endings just an illusion...

> >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?

You missed the point entirely, did you? LF is the standard EOL in C (as
well as in many other languages that is used by Git developers). Thus,
naturally Git internally considers only LF as the only true EOL, and if
it happened that you store files with different EOLs, they should be
converted during import to the Git repository. And, yes, C programs
do use printf and other C library functions to write text files...
Why do you think Microsoft C library does convert CRLF on reading and
writing for text files? Or that is another illusion?

> >>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.

What is your point?! Git *does* respect your autocrlf choice. But it
also respects *other* people choice to have what they want in *their*
repositories.

>
> >>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.

What I am saying is that having CRLF for text files is a mistake, and it
should be dealt as that. Perhaps, something can be added to help people
to deal with their past mistakes, but by no means, we should encourage
to produce more crap... So far, I have not heard any rational suggestion,
let alone seeing your code that implements it.

>
> My point is that if I commit two files with different line endings, I  
> want Git to store them that way.

If you want something insane, you can have that, but the insane mode is
not for normal users. So, it should not be default.

> Works on Linux by default, doesn't  
> work on Windows by default.

So what? Sane people do NOT store text files with different endings,
especially on Linux...

> >>>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.

What problems? Isn't true that these problems were caused in the first
place by having autocrlf=false? If you prefer CRLF for your text files
what exactly is your problem with having crlf=true? Your old history?
But why should other users suffer because you have messed up file
endings in your repository?

Perhaps, it would be nicer if Git saved autocrlf when created a new
repository, so if the global setting is changed, it will not affect
already existing repositories. I believe something like that can be
added. In fact, Junio mentioned about this possibility before, but
you do not seem to care to do _anything_ to improve the situation,
and when I say to do something, I don't mean just empty flame.

>
> >>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

That is *exactly* why autocrlf=true should be default on Windows, as you
want to have at the very moment when a new repository is created! Thanks!

And, yes, the file is shown changed. You can have the same effect with
SVN if you did not set svn:eol-style=native when added a file and then
change it to svn:eol-style=native later. The issue here is that you have
wrong ending for text files in the first place.

> >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.

I know, and I also know that I don't like crap in my repository and
I don't like any tool that encourages users to put every crap in it.
And, no, I don't think that that check-in-all-crap-I-have should be
the default mode for Git. If you like that mode, you probably can set
autocrlf=false and also create some nice alias for git commit -a, so
you check-in all crap crap at once, but I can't care less about all
problems that you'll have after that.

>
> >>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.

*Shrug* All I can say I don't remember any problem like this with CVS,
and it did conversion automatically for us. Unfortunately, it converted
binary files too, so new users had to be taught about using 'cvs -kb'
or their binary files would be mutilated. So, I am pretty sure about
this. Perhaps, the difference was that we has always had our CVS server
on Linux, but we have not recompiled anything.

> 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.

Sharing working directories is a real issue. I hit it myself once with
CVS. Fortunately, git provides a good solution: autocrlf=input.

>
> >>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,

Sure, they will. It is insane ending to store in your repo. It was
exactly my point all way along, but somehow you missed that...

> and (b) everyone who clones from me has to make the same  
> setting manually, or they won't follow the same convention.

If people follow sane settings, they do not have to change anything
manually, and they can edit file using *their* preferable EOLs. However,
if you publish a repo with CRLF for text files, *you* create problems
for other people, and they have every right to blame you for that.

>
> 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.

Add the update hook, which will prevent pushes with the wrong ending.

>
> >>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.

Well, I don't see much historical value in seeing what files had
what ending and at what time. So, usually, it is a good idea to
clean up them when you convert your repo into Git. But as I said
above, you can try to use .gitattributes.

Anyway, autocrlf=true makes much more sense as default, because
newly created repositories and files in them will have the correct
ending.

> >>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".

Naw! autocrlf=false means you take responsibility for EOL in files that
you check in.  In fact, no version control system that can verify that
all what you check-in makes sense. So it can only _facilitate_ you in
creating good patches, but it cannot force you to do things in the right
way. Thus, any option that helps people to do their job is good, but you
cannot foresee all use cases, so it should be always choice to turn this
automatically thing off when it is necessary.

> 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?

Who are you to tell what cost is high and low? Why do you think that
you should dictate your idea of cost to *everyone*?


Dmitry
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

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

Tarmigan Casebolt
In reply to this post by Eyvind Bernhardsen
On Wed, Jul 30, 2008 at 12:25 PM, Steffen Prohaska <[hidden email]> wrote:

>
> On Jul 30, 2008, at 8:33 PM, Avery Pennarun wrote:
>
>> On 7/30/08, Steffen Prohaska <[hidden email]> wrote:
>>
>>> What matters is that git gives you exactly back what you committed.  It
>>> does so with core.autocrlf=true, unless you check out with a different
>>> setting for autocrlf.
>>
>> You can tell that this statement isn't quite true because if you have
>> a file with mixed LF and CRLF line endings, which I do (thanks,
>> Windows!) then CRLF->LF conversion is not a reversible operation.
>> Interestingly LF->CRLF still is (because an LF->CRLF'd file will never
>> have a bare LF, and on such a subset of files, CRLF->LF is
>> reversible).
>>
>> Also note that core.autocrlf=input is *definitely* not a perfectly
>> reversible operation.
>
> You are absolutely right.  The files your describe are modified by git,
> because they are "invalid" text files, as git defines them.

For all I care, git can consider the files as binary, but by *default*
I should get back the same as I put in.

[For the rest of my rant, I am referring to the default configuration
of autocrlf on windows]

> For git's
> autocrlf mechanism to work, a text file is only allowed to have a
> *single* type of line endings.

Git's autocrlf mechanism can be a nice feature.  But by default it
should not be on (even on windows) because it can modify screw up my
files.

To be clear: when I say "git checkout" I want to get EXACTLY the same
bits as went in when I did "git add" and "git commit".  Any other
default is broken.

> Otherwise it is broken and git tries to
> help you fixing it.

My files were NOT broken when I put them into git.  I committed them
known good state.  If msysgit changes them by *default* , then msysgit
is broken.

IF you are working on a cross platform project, then setting autocrlf
on windows might be nice.  But having it on by *default* is broken.

Thanks,
Tarmigan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

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

Dmitry Potapov
On Sun, Aug 03, 2008 at 09:54:42AM -0700, Tarmigan wrote:
>
> For all I care, git can consider the files as binary, but by *default*
> I should get back the same as I put in.

Sorry, but Git is a source control system, and by definition the
main focus is on *text* files. Storying binary files is *exception*
not the rule. And the default settings should respect exactly that
fact.

> > For git's
> > autocrlf mechanism to work, a text file is only allowed to have a
> > *single* type of line endings.
>
> Git's autocrlf mechanism can be a nice feature.  But by default it
> should not be on (even on windows) because it can modify screw up my
> files.
>
> To be clear: when I say "git checkout" I want to get EXACTLY the same
> bits as went in when I did "git add" and "git commit".  Any other
> default is broken.

You will get exactly the same unless you change your autocrlf settings.
There are very rare situation where automatic heuristic can be wrong,
but even then you will be warned about that the file you are going to
checkout different. See core.safecrlf.

>
> > Otherwise it is broken and git tries to
> > help you fixing it.
>
> My files were NOT broken when I put them into git.  I committed them
> known good state.  If msysgit changes them by *default* , then msysgit
> is broken.

Text files committed with CRLF inside of your repository is BROKEN by
definition! So you had BROKEN state in the first place.

Of course, changing the global autocrlf setting should not change
autocrlf settings in already existing repositories, as it currently
does.  Care to provide patch?


Dmitry
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

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

Tarmigan Casebolt
On Sun, Aug 3, 2008 at 10:33 AM, Dmitry Potapov <[hidden email]> wrote:
> On Sun, Aug 03, 2008 at 09:54:42AM -0700, Tarmigan wrote:
>>
>> For all I care, git can consider the files as binary, but by *default*
>> I should get back the same as I put in.
>
> Sorry, but Git is a source control system,

I think this is the heart of the disagreement.  What I love about git
is that git trusts me, the user, and it trusts my files.  It doesn't
change the encoding of my filenames by default.  It doesn't do keyword
expansion by default.  It doesn't change the case of filenames by
default.

If git is not willing to change the encoding/case of file*names* by
default, how is it acceptable to change the *content* of the files
themselves?

Yes, some systems that define themselves as "source control
management" systems make these changes for you.  But that sometimes
leads to frustrating and hard to understand (to the user) behavior.
Git has a very simple and transparent mental model, which is one of
it's greatest strengths.  In my humble opinion, autocrlf breaks this
simple "content tracker" model.

Breaking this mental model bothers me much more than the practical
issues involved with autocrlf, so I'm just going to drop that line of
argument.

Thanks,
Tarmigan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

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

Dmitry Potapov
On Sun, Aug 03, 2008 at 11:54:34AM -0700, Tarmigan wrote:
> On Sun, Aug 3, 2008 at 10:33 AM, Dmitry Potapov <[hidden email]> wrote:
> > On Sun, Aug 03, 2008 at 09:54:42AM -0700, Tarmigan wrote:
> >>
> >> For all I care, git can consider the files as binary, but by *default*
> >> I should get back the same as I put in.
> >
> > Sorry, but Git is a source control system,
>
> I think this is the heart of the disagreement.

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.

> What I love about git
> is that git trusts me, the user, and it trusts my files.

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.

> It doesn't change the encoding of my filenames by default.

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.

> It doesn't do keyword expansion by default.

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.

> It doesn't change the case of filenames by default.

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?

> If git is not willing to change the encoding/case of file*names* by
> default, how is it acceptable to change the *content* of the files
> themselves?

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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html