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

[PATCH/RFC 0/3] Per-repository end-of-line normalization

From
Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com>
Date
May 6, 2010, 22:27 UTC
Message-ID
<cover.1273183206.git.eyvind.bernhardsen@gmail.com>
In-Reply-To
<x2s40aa078e1005061340vaf404ab3g30b2b98ca408205@mail.gmail.com>

This discussion couldn't be more timely, as I've recently acquired a desperate need to solve CRLF problems at $dayjob. This patch series introduces a new way of turning on autocrlf normalization by splitting the configuration into two:

- An attribute called "auto-eol" is set in the repository to turn on
  normalization of line endings.  Since attributes are content, the
  setting is copied when the repository is cloned and can be changed in
  an existing repository (with a few caveats).  Setting this attribute
  is equivalent to setting "core.autocrlf" to "input" or "true".
- A configuration variable called "core.eolStyle" determines which type
  of line endings are used when checking files out to the working
  directory.

How does this solve the current problems with core.autocrlf? First, let's enumerate them:

1. Setting core.autocrlf in your global or system configuration is a
pain since git will get confused whenever you work in a repository which
contains CRLF line endings.  If you have to work in both repositories
with normalization and repositories with mixed line endings, you have no
choice but to set core.autocrlf in each repository individually.
2. Setting core.autocrlf in an individual repository would be okay
except that naive users will do it after they have already cloned:
unless core.autocrlf is set globally, the clone will have the wrong line
endings, and the user needs to know how to refresh it manually (rm -rf *
&& git checkout -f).
3. Once somebody does it, _everyone_ has to do it: if someone checks in
a file with CRLFs, that file will cause trouble for everyone who has
autocrlf set.  That someone can be a Linux user who just copied a file
from Windows and didn't think to convert the line endings (BT, DT).
4. Once a repository contains CRLFs autocrlf can never sanely be
enabled; the CRLFs can be normalized in a commit, but there's no way to
say "all commits after this one are normalized, those that came before
were not".
5. On the other hand, setting core.autocrlf means that git no longer
stores your files in their pristine, natural state; if you _know_ that
your repository will never be used by anyone whose EOL preference
differs from your own, it seems wasteful and dangerous to normalize
those line endings.

I used an attribute to enable line-ending conversion because it seems to be a good idea to have line ending normalization be a property of the content rather than the repository's or user's configuration. "If anybody wants to clone my repository, they'd better be prepared to normalize their EOLs".

Which EOLs the user wants to use obviously can't be a part of the content, so part is still a configuration variable.

"core.autocrlf" is still available and allows someone working on, say, git.git from Windows to have CRLFs in their working directory without requiring any changes to the repository.

For backwards compatibility, "core.autocrlf" overrides "auto-eol" if it is set, and "core.eolStyle" can be set to "false" to disable conversion even when "auto-eol" is set.

For my own part, I'll be implementing this change company-wide shortly. We have an existing repository with a large body of code that contains a heady mix of CRLF and LF files, but our newly introduced build system requires everything to be normalized to CRLF (don't ask). There's no sane way of handling this using autocrlf; all developers would have to know when to set core.autocrlf and remember to set it on every clone, or even on every checkout.

I hope someone else will find it useful.
Eyvind Bernhardsen (3):
  Add "auto-eol" attribute and "core.eolStyle" config variable
  Add tests for per-repository eol normalization
  Add per-repository eol normalization
 Documentation/config.txt        |   11 ++-
 Documentation/gitattributes.txt |   92 +++++++++++++++++---
 Makefile                        |    3 +
 cache.h                         |   19 ++++
 config.c                        |   16 +++-
 convert.c                       |   48 ++++++++---
 environment.c                   |    1 +
 t/t0025-auto-eol.sh             |  180 +++++++++++++++++++++++++++++++++++++++
 8 files changed, 339 insertions(+), 31 deletions(-)
 create mode 100755 t/t0025-auto-eol.sh
Previous: Anthony W. YoungmanNext: Eyvind Bernhardsen
Message 16 of 82 in “What should be the CRLF policy when win + Linux?”
  1. matMay 5, 2010
  2. Ramkumar RamachandraMay 5, 2010
  3. matMay 6, 2010
  4. Erik Faye-LundMay 6, 2010
  5. hasen jMay 6, 2010
  6. Wilbert van DolleweerdMay 6, 2010
  7. hasen jMay 6, 2010
  8. Linus TorvaldsMay 6, 2010
  9. Erik Faye-LundMay 6, 2010
  10. hasen jMay 6, 2010
  11. Linus TorvaldsMay 6, 2010
  12. Erik Faye-LundMay 6, 2010
  13. hasen jMay 6, 2010
  14. Erik Faye-LundMay 6, 2010
  15. Anthony W. YoungmanMay 18, 2010
  16. 0/3 Per-repository end-of-line normalizationEyvind Bernhardsen, May 6, 2010
  17. 1/3 Add "auto-eol" attribute and "core.eolStyle" config variableEyvind Bernhardsen, May 6, 2010
  18. 2/3 Add tests for per-repository eol normalizationEyvind Bernhardsen, May 6, 2010
  19. 3/3 Add per-repository eol normalizationEyvind Bernhardsen, May 6, 2010
  20. Avery PennarunMay 6, 2010
  21. Avery PennarunMay 6, 2010
  22. Erik Faye-LundMay 7, 2010
  23. Junio C HamanoMay 7, 2010
  24. Avery PennarunMay 7, 2010
  25. Linus TorvaldsMay 7, 2010
  26. Linus TorvaldsMay 7, 2010
  27. Avery PennarunMay 7, 2010
  28. Linus TorvaldsMay 7, 2010
  29. Avery PennarunMay 7, 2010
  30. Linus TorvaldsMay 7, 2010
  31. Avery PennarunMay 7, 2010
  32. Linus TorvaldsMay 7, 2010
  33. Linus TorvaldsMay 7, 2010
  34. Eyvind BernhardsenMay 7, 2010
  35. Linus TorvaldsMay 7, 2010
  36. Eyvind BernhardsenMay 7, 2010
  37. Linus TorvaldsMay 7, 2010
  38. Avery PennarunMay 7, 2010
  39. Eyvind BernhardsenMay 7, 2010
  40. Linus TorvaldsMay 7, 2010
  41. Linus TorvaldsMay 7, 2010
  42. Linus TorvaldsMay 7, 2010
  43. Avery PennarunMay 7, 2010
  44. hasen jMay 7, 2010
  45. Linus TorvaldsMay 7, 2010
  46. hasen jMay 7, 2010
  47. Linus TorvaldsMay 7, 2010
  48. hasen jMay 8, 2010
  49. Linus TorvaldsMay 8, 2010
  50. hasen jMay 8, 2010
  51. Linus TorvaldsMay 8, 2010
  52. hasen jMay 8, 2010
  53. Robert BuckMay 8, 2010
  54. Avery PennarunMay 8, 2010
  55. hasen jMay 8, 2010
  56. Robert BuckMay 8, 2010
  57. Avery PennarunMay 8, 2010
  58. Avery PennarunMay 8, 2010
  59. Avery PennarunMay 7, 2010
  60. Dmitry PotapovMay 8, 2010
  61. Linus TorvaldsMay 8, 2010
  62. Dmitry PotapovMay 8, 2010
  63. Eyvind BernhardsenMay 9, 2010
  64. Robert BuckMay 9, 2010
  65. Avery PennarunMay 7, 2010
  66. Eyvind BernhardsenMay 7, 2010
  67. Nicolas PitreMay 7, 2010
  68. Avery PennarunMay 7, 2010
  69. Nicolas PitreMay 7, 2010
  70. Avery PennarunMay 7, 2010
  71. Nicolas PitreMay 7, 2010
  72. Avery PennarunMay 7, 2010
  73. A Large Angry SCMMay 7, 2010
  74. Avery PennarunMay 7, 2010
  75. Linus TorvaldsMay 7, 2010
  76. Nicolas PitreMay 7, 2010
  77. Junio C HamanoMay 7, 2010
  78. Eyvind BernhardsenMay 7, 2010
  79. Finn Arne GangstadMay 7, 2010
  80. Avery PennarunMay 7, 2010
  81. Eyvind BernhardsenMay 7, 2010
  82. GelonidaMay 7, 2010

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.