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
Dmitry Potapov <dpotapov@gmail.com>
Date
Jul 24, 2008, 16:53 UTC
Message-ID
<20080724165335.GW2925@dpotapov.dyndns.org>
In-Reply-To
<7vej5kfs0w.fsf@gitster.siamese.dyndns.org>
On Wed, Jul 23, 2008 at 10:07:43AM -0700, Junio C Hamano wrote:
Show 8 quoted lines
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > However, if you want to avoid CRs to _enter_ the repository, when you have 
> > a lot of binary files tracked, you _do_ want to force all repositories to 
> > crlf=input.
> 
> If you are on a sane system, you do not even want to pay the price of
> conversion. 

If you do not have CRLF then there will be no conversion, so you pay only the price of check. The relative cost of that check obviously depends on what other operations are. I believe that the worst case for this check will be when there is no other operations, just re-reading files, so I did:

# touch all files to force git re-read them... git ls-files | xargs touch time git status

Here is the average based on 3 attempts: 0.232s with autocrlf=false 0.265s with autocrlf=input (14% increase)

Of course, without touching files, git-status will take the same time in both cases (about 0.026s in my testing), and touching all files not very interesting from the practical point of view.

So, I decided to do something more practical, like applying 100 patches. Here are my results:

         false     input
         ------   -------
         7.409s   7.603s
         7.592s   7.239s
         7.617s   7.402s
         ------   -------
Average: 7.539s   7.415s

autocrlf=input turned out to be even slightly faster, but the difference is not statistically significant.

So, though it is obvious that autocrlf=input clearly adds some overhead, I believe it is negligable in most practical cases as there are much more expensive operations. And you can always turn autocrlf off, if you are sure that you never have files with the wrong line ending.

> Only people on systems with CRLF line endings should pay the
> price (because your aim is to convert on such systems).

Unfortunately, it is not so clearly cut. Some people may work on Unix but share files with Windows using network shares or emails.

> Are we throwing
> that out of the window when the project decides to use gitattributes?

I am not sure that I understand your question. In any case, Dscho's patch did not change the default, so it did not penalize anyone except explicitly asked about that by setting crlf on some files. I would like also to notice that setting crlf on some files (in contrast to unsetting it!) is rarely necessary in practice if all users have sane settings for autocrlf.

> 
> How about setting autocrlf automatically on mingw/msys/cygwin versions,
> perhaps via templates or a patch to init-db?  Would that, combined with
> user education, be a viable alternative?

Perhaps, it is good compromise for now, considering that Windows users have most troubles with that... I really don't mind seeing 'input' as default on other platforms, but I won't insist on that.

Dmitry
Previous: Johannes SchindelinNext: Johannes Schindelin
Message 56 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.