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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 25. juli. 2008, at 16.01, Dmitry Potapov wrote:

On Fri, Jul 25, 2008 at 02:30:16PM +0200, Eyvind Bernhardsen wrote:

Fair enough.  Did you read the rest of my email to see when I think
Git should mess with content?  I've thought about it, and being able
to do stuff like this in .gitattributes would work for me:

* eol=auto
*.bat eol=crlf
Makefile eol=lf
bin/magic-binary eol=none

I.e. "detect line endings and do CRLF->LF conversion on all files
except *.bat (*->CRLF), Makefile (*->LF) and bin/magic-binary (do
nothing)".

I suppose "* eol=auto" means to convert CRLF->LF on checkin and
LF->native on checkout?

That's the idea, yes, with "native" being configurable.

Also, perhaps, it should be also possible to explicitly specify:
*.txt eol=native
which is the same as 'auto' but without guessing whether it is text
or not.

Yes!  Good catch, that needs to be possible.

...but "core.autocrlf" is not versioned and applies to _all_
repositories, and anyone who doesn't have the correct setting can mess
the repository up.

I think the real issue here is not as much about being or not being
versioned, but about forcing and not forcing anything on users.

The reason I want versioning is to fix the problem of enforcing normalised line endings in repositories with checked-in CRLFs; I'm not sure how to solve it any other way, but I'm open to suggestions.

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! :)

The same can be said about your
* eol=auto
It forces conversion on everyone, even on those who do not need it.
Of course, you can say those projects that do not have the problem with
clueless users putting text files with incorrect end-of-lines will not
have lines like that in their .gitattribute. Yet, if I participate in
that project, why do I have to pay the price for this conversion just
because someone stupid can mess up line-endings?

It's about correctness: if the repository isn't supposed to have CRs in any text files, that needs to be enforced. You might not be stupid, but that doesn't mean you won't ever take a file that was created on Windows and commit it to the repository on Linux. If the tool used to create the file was CR-damaged, there goes the repository's LF-only policy.

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

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?

There's also no way of saying "this file should
have LF line endings, even with autocrlf=true".

Actually, there is

*.sh crlf=input

i.e. I want my shell files to have LF even I normally use CRLF for
all other files (on Windows).

Won't they still be converted to CRLF on checkout when autocrlf=true on Windows?

One problem is that the autocrlf setting mixes "I want LF only in my
repositories" and "I like to have CRLFs in my working directory" into
one config variable.  Instead, I'd like to have a config setting that
specifies which line ending form I prefer: "when a text file is marked
eol=auto, convert LFs to CRLFs on checkout".

Following your style above, I believe it should be defined as
native-eol=crlf

Yes, that sounds right.

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?

This is the reason the setting needs to be a per-repository policy and not a user configuration; users should not be able to configure away correctness, but they shouldn't be penalised unnecessarily for it, either.
--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux