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
Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com>
Date
May 9, 2010, 07:49 UTC
Message-ID
<42C31791-ACD3-4D43-99E6-287F9E63EDAB@gmail.com>
In-Reply-To
<20100508234222.GA14069@dpotapov.dyndns.org>
On 9. mai 2010, at 01.42, Dmitry Potapov wrote:
> On Sat, May 08, 2010 at 02:54:35PM -0700, Linus Torvalds wrote:
[...]
Show 17 quoted lines
>> You could talk about "binary" vs "text", and it would make sense, but your 
>> argument that "eol" is somehow better than "crlf" is just insane.
>> 
>> So I could certainly see
>> 
>> 	*.jpg binary
>> 	*.txt text
>> 
>> making sense. But "eol" is certainly no better than "crlf". 
> 
> What about .sln files? They are xml files with CRLF ending. Does it mean
> they are binary? Based on how it is stored, it is certainly binary, but
> when it comes to "diff" or even "merge" you may want to think about them
> as text, and, in general, people tend to think about them as text files.
> 
> Another example is shell scripts. You really want them to be LF even on
> Windows. So, is it a binary file too?
I think "binary" and "text" are the wrong things to talk about in this case.
If we were to following Avery's suggestion that we look at what we would have implemented had autocrlf not already existed, it would be better to call "crlf" something like "eolconv".  You're not saying that a file is text or binary as such, rather that "I want eol conversion for this file" or "I don't want eol conversion for this file".
Flagging a file as "-eolconv" because it should always have LFs or always CRLFs seems logical to me.  "eolconv=auto" also makes sense.
[...]
Show 8 quoted lines
>> In the end, crlf is what we have. We're not getting rid of it, so if 
>> somebody were to actually rename it, that would just mean that there are 
>> _two_ different ways to say the same thing. And quite frankly, I think 
>> that's worse than what we have now, so I don't think it's worth it.
> 
> I was not sure myself that the idea of renaming worth it... While I do
> think that "eol" is a better name than "crlf", but not by big margin,
> and as you said crlf is what we have now... so be it...
Renaming "crlf" might not be worth it, but thinking about what it should look like definitely is worth it.  Since I already have a patch series that changes this area, I'd like for it to be future proof.
I think the idea that we're stuck with "crlf" (or any bad ui design) for ever and ever is depressing, and I reject it.  It would be easy to create a new attribute with a better name that is the same setting under the hood, and deprecate "crlf".  The old attribute would still work in existing repositories (indefinitely, if needs be), but new users wouldn't have to be confused by its poor name.
I'm not saying I want to replace "crlf" right now!  I'm just saying that it makes sense to think about how we would want to replace it, and try not to introduce any new change that will make it harder to do the right thing later.
-- 
Eyvind
Previous: Dmitry PotapovNext: Robert Buck
Message 63 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.