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

Re: [PATCH 3/3] Teach "git branch" about --new-workdir

From
Marius Storm-Olsen <marius@trolltech.com>
Date
Jul 24, 2007, 18:02 UTC
Message-ID
<46A63EAA.6080203@trolltech.com>
In-Reply-To
<Pine.LNX.4.64.0707241431540.14781@racer.site>
Show 17 quoted lines
>> So, it's look like this ('yes' mean CRLF EOL):
>>     Repo | Working dir | Convert EOL?
>>     ---------------------------------
>> 1)  -      LF            no
>> 2)  -      CRLF          yes
>> 3)  LF     LF            no
>> 4)  LF     CRLF          yes
>> 5)  CRLF   LF            no
>> 6)  CRLF   CRLF          yes
>>
>> The problem is that currently 6) is 'yes', and turns the file into
>> a LF file, which it shouldn't.
> 
> Shouldn't it?  But then you should set core.autocrlf = false, no?
> 
> AFAIU the purpose of autocrlf is to _always_ have UNIX line endings
> in the checked in stuff.

I realize that I might be talking 'out of context', so to speak; so it's hard to see where I'm going with this. So, I'll start from the beginning. :-)

1) IMO, git should on Windows always do CRLF conversion, as this is what
Windows developers in general expect. (CRLF text-files that is, not the
conversion.) Meaning that
    core.autocrlf = Windows
by default. Where 'Windows' would be of true/false value which is true
when on Windows and false when on other platforms. (Not that we should
_have_ such an option, but the concept at least.)
2) Most Windows developers in the category above currently do
    git-config --global core.autocrlf true
once, and be done with it.
However, for every text-file they want in the repo which _should_
contain CRLF EOLs they would have to add this file to either a
.gitattributes file in that same directory, or to
    .git/info/attributes
with the
    <filepath> -crlf
to ensure that the autocrlf conversion is not triggered for those files.
Now, for Unix users that seems like a small price to pay, and of course
_they_ don't have to worry about it. It's up to the Windows developers
to take the pain and add these .gitattributes files, and keep track
whenever new CRLF files appear in the repo from other non-Windows
developers.
3) My suggestion in the previous mail would to a large extent alleviate
this problem, since once in the repo with CRLF lineendings the 'autocrlf
conversion' routine wouldn't automatically try to convert it back to LF
endings, even if this file is not in any attributes file with '-crlf'.
It would mean that we wouldn't have to add _any_ files to attributes
files at all, but only have to teach git a way to avoid crlf-converting
a given file when commiting a change. For example, on Windows you could
then do something like:
    git update-index --crlf my_DOS_file.txt
    git commit -m "Add a CRLF file to the repo"
then forget about it.

No need to add a .gitattributes in your own repo. No need for linux users to worry about Windows users. No need to Windows users to clean up the repos for the linux users.

IMO, the .gitattributes file with '<filepath> -crlf' is a hack-fix to a
problem we shouldn't be having in the first place. We should be able to
write in the git documentation:
   "Text files are stored with Unix line ending in Git. If you need a
text file to contain DOS line endings on all platforms, use the --crlf
option on the update-index command."... or something to that effect.

Ok, a bit longer mail than I expected/wanted, but I hope it explains the idea successfully, and convincingly. ;-)

Later!

-- .marius

Previous: Johannes SchindelinNext: Johannes Schindelin
Message 34 of 46 in “Teach "git branch" about --new-workdir”
  1. 3/3 Teach "git branch" about --new-workdirJohannes Schindelin, Jul 22, 2007
  2. Daniel BarkalowJul 22, 2007
  3. Johannes SchindelinJul 22, 2007
  4. Julian PhillipsJul 22, 2007
  5. Johannes SchindelinJul 22, 2007
  6. Julian PhillipsJul 22, 2007
  7. Johannes SchindelinJul 22, 2007
  8. Julian PhillipsJul 22, 2007
  9. Jakub NarebskiJul 22, 2007
  10. Johannes SchindelinJul 22, 2007
  11. Johannes SchindelinJul 22, 2007
  12. Shawn O. PearceJul 23, 2007
  13. Junio C HamanoJul 23, 2007
  14. Shawn O. PearceJul 23, 2007
  15. Shawn O. PearceJul 23, 2007
  16. Johannes SchindelinJul 23, 2007
  17. Johannes SchindelinJul 23, 2007
  18. Marius Storm-OlsenJul 24, 2007
  19. Johannes SchindelinJul 24, 2007
  20. Junio C HamanoJul 24, 2007
  21. Johannes SchindelinJul 24, 2007
  22. Marius Storm-OlsenJul 24, 2007
  23. Julian PhillipsJul 24, 2007
  24. Marius Storm-OlsenJul 24, 2007
  25. Johannes SchindelinJul 24, 2007
  26. Josef WeidendorferJul 24, 2007
  27. Johannes SchindelinJul 24, 2007
  28. Josef WeidendorferJul 24, 2007
  29. Jakub NarebskiJul 25, 2007
  30. Johannes SchindelinJul 24, 2007
  31. Marius Storm-OlsenJul 24, 2007
  32. Marius Storm-OlsenJul 24, 2007
  33. Johannes SchindelinJul 24, 2007
  34. Marius Storm-OlsenJul 24, 2007
  35. Johannes SchindelinJul 24, 2007
  36. Marius Storm-OlsenJul 24, 2007
  37. Alex RiesenJul 24, 2007
  38. Marius Storm-OlsenJul 25, 2007
  39. Johannes SchindelinJul 25, 2007
  40. Steven GrimmJul 25, 2007
  41. Andy ParkinsJul 25, 2007
  42. Marius Storm-OlsenJul 25, 2007
  43. Johannes SchindelinJul 25, 2007
  44. Linus TorvaldsJul 25, 2007
  45. Christian MICHONJul 26, 2007
  46. Julian PhillipsJul 23, 2007

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.