git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Eyvind Bernhardsen <eyvind-git@orakel.ntnu.no>
Date
Jul 29, 2008, 21:17 UTC
Message-ID
<A8BF9951-AB9D-4391-A6CB-E9778064F4A8@orakel.ntnu.no>
In-Reply-To
<20080729134619.GB7008@dpotapov.dyndns.org>
On 29. juli. 2008, at 15.46, Dmitry Potapov wrote:
Show 8 quoted lines
> 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.

Show 14 quoted lines
>>> 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.

Show 15 quoted lines
> 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.

Show 7 quoted lines
>> 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.

Show 15 quoted lines
>> 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.

Show 8 quoted lines
>> 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.

[...]
Show 16 quoted lines
>>> 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").

Show 5 quoted lines
> 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.

Show 24 quoted lines
>> 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
Previous: Dmitry PotapovNext: Steffen Prohaska
Message 36 of 58 in “Respect crlf attribute even if core.autocrlf has not been set”
  1. Respect crlf attribute even if core.autocrlf has not been setJohannes Schindelin, Jul 22, 2008
  2. Dmitry PotapovJul 22, 2008
  3. Johannes SchindelinJul 22, 2008
  4. Dmitry PotapovJul 23, 2008
  5. Junio C HamanoJul 23, 2008
  6. Johannes SchindelinJul 23, 2008
  7. Respect crlf attribute in "git add" even if core.autocrlf has not been setJohannes Schindelin, Jul 23, 2008
  8. Steffen ProhaskaJul 23, 2008
  9. Johannes SchindelinJul 23, 2008
  10. Dmitry PotapovJul 23, 2008
  11. Steffen ProhaskaJul 24, 2008
  12. Johannes SchindelinJul 24, 2008
  13. Dmitry PotapovJul 24, 2008
  14. Dmitry PotapovJul 24, 2008
  15. Johannes SchindelinJul 24, 2008
  16. Steffen ProhaskaJul 24, 2008
  17. Avery PennarunJul 24, 2008
  18. Johannes SchindelinJul 24, 2008
  19. Robin RosenbergJul 24, 2008
  20. Johannes SchindelinJul 24, 2008
  21. Junio C HamanoJul 23, 2008
  22. Johannes SchindelinJul 23, 2008
  23. Joshua JensenJul 23, 2008
  24. Avery PennarunJul 23, 2008
  25. Johannes SchindelinJul 23, 2008
  26. Eyvind BernhardsenJul 23, 2008
  27. Johannes SchindelinJul 23, 2008
  28. Eyvind BernhardsenJul 24, 2008
  29. Johannes SchindelinJul 25, 2008
  30. Eyvind BernhardsenJul 25, 2008
  31. Dmitry PotapovJul 25, 2008
  32. Eyvind BernhardsenJul 25, 2008
  33. Johannes SchindelinJul 26, 2008
  34. Eyvind BernhardsenJul 29, 2008
  35. Dmitry PotapovJul 29, 2008
  36. Eyvind BernhardsenJul 29, 2008
  37. Steffen ProhaskaJul 30, 2008
  38. Avery PennarunJul 30, 2008
  39. Steffen ProhaskaJul 30, 2008
  40. Avery PennarunJul 30, 2008
  41. Dmitry PotapovJul 30, 2008
  42. Avery PennarunJul 30, 2008
  43. TarmiganAug 3, 2008
  44. Dmitry PotapovAug 3, 2008
  45. TarmiganAug 3, 2008
  46. Dmitry PotapovAug 4, 2008
  47. Dmitry PotapovJul 30, 2008
  48. Eyvind BernhardsenAug 2, 2008
  49. Dmitry PotapovAug 3, 2008
  50. Robin RosenbergJul 23, 2008
  51. Junio C HamanoJul 23, 2008
  52. Johannes SchindelinJul 23, 2008
  53. Dmitry PotapovJul 23, 2008
  54. Junio C HamanoJul 23, 2008
  55. Johannes SchindelinJul 23, 2008
  56. Dmitry PotapovJul 24, 2008
  57. Johannes SchindelinJul 24, 2008
  58. Dmitry PotapovJul 24, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.