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

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

From
Avery Pennarun <apenwarr@gmail.com>
Date
May 7, 2010, 19:58 UTC
Message-ID
<g2s32541b131005071258s92e058bakc8f3a4df1e1dc634@mail.gmail.com>
In-Reply-To
<alpine.LFD.2.00.1005071240590.901@i5.linux-foundation.org>

On Fri, May 7, 2010 at 3:45 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote:

Show 10 quoted lines
> On Fri, 7 May 2010, Avery Pennarun wrote:
>> 1) Whether a project has files that should be EOL-converted
>> automatically (we seem to all agree that this is set in
>> .gitattributes, whichever attribute is used).
>>
>> 2) Whether a particular person wants those particular files to be
>> EOL-converted, and what to convert them to.
>
> So? If we were to have a .gitconfig file, then both of those things would
> just work.

No! The whole point is that each user *does* still want to be able to decide how to convert the files tagged by the crlf gitattribute (or a new attribute, I don't care). Setting this in a .gitconfig file inside the project is pointless; I need it in my *personal* config. msysgit users want to set it globally to CRLF by default, Linux or cygwin users probably want to set it to LF by default.

So #1 is useful to have in the repo, #2 is not.

I am a real live example of this. For our Delphi projects at work, I want to check it out with LF on my Linux machine (so I can patch/diff/merge/grep/edit/etc easily), and CRLF on my Windows machine (so that the Delphi IDE doesn't get confused). Other projects I want to have pure LF on both Linux and Windows, so setting core.autocrlf=true globally will break things.

Eyvind's proposal (or a similar proposal where his new attribute is just the crlf attribute) will get me and all my co-workers the wonderful correct behaviour *by default*; the current behaviour, or an in-repo .gitconfig, will not. The key feature is the new core.eolStyle option, not whether or not we add a new attribute.

> That said, I don't think the extra .gitconfig is even worth it, the same
> way I do _not_ think Eyvind's extra .gitattributes things are worth it.

Do you even use any CRLF projects? If not, then presumably none of the options will seem worth it. :)

But the current behaviour really doesn't work for people who need CRLF conversion, and an in-repo .gitconfig file won't help them. core.eolStyle + a change to crlf attribute semantics will.

Have fun,
Avery
Previous: Linus TorvaldsNext: Linus Torvalds
Message 31 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.