According to the documentation on core-eol
Sets the line ending type to use in the working directory for files that are marked as text (either by having the text attribute set, or by having text=auto and Git auto-detecting the contents as text).
So question #1 is: Does core-eol work at all without having a .gitattributes file?
Question #2 is is this for checkout to the working directory or check-in from the working directory to index? Or both?
With git for windows 2.33.1 and global settings (no local) for core.autocrlf = false (so it does not override core.eol) and core.eol = crlf and running Git Bash (echo command > results in eol=LF)
1. git config --global core.autocrlf false
2. git config --global core.eol crlf
3. mkdir testEOL
4. cd testEOL
5. echo Hello > hello.txt // file has LF eol
6. git init
7. git add . // file still has LF eol in working directory
8. git commit -m "Initial commit"
9. echo "* text" > .gitattributes
10. git add . // file has LF eol, however -> warning: LF will be replaced by CRLF in .gitattributes.
11. git commit -m "Git attributes"
12. echo New Line >> hello.txt
13. git add . // warning: LF will be replaced by CRLF in hello.txt.
14. git commit -m "Change to hello"
14a. git rm hello.txt
15. git reset --hard HEAD // EDIT: hello.txt has CRLF
The answers to the questions seem:
- No (line 7)
- Check-in and check-out (lines 10,13 and 15) - after removal of files fist (see updated 14a)
Is it just my experiment or is this true?
CodePudding user response：
The documentation states that core.eol only affects files with the text attribute set. If that attribute is not set, the Git looks at core.autocrlf to determine it, and setting that would override the core.eol value. So if you want to control the end of line, you'll need to use a .gitattributes file to set the attribute.
The core.eol option and and eol attribute affect only what is in the working tree. Any file with the text attribute will have its line endings converted to LF when stored in the repository itself, and then that attribute or setting will determine what line endings it has in the working tree.
The warning you see is telling you that your file in the working tree has LF (because you created it with Unix shell tools) but your settings for the working tree have requested that it have CRLF in the working tree. As a result, you might end up with a different behavior on a future checkout than you have now.
Doing a git add doesn't change the file in the working tree to have the specified endings, only add it to the repository with LF endings. If you want to change the line endings in the working tree, you need to force the file to be checked out again, which you've done with git reset --hard.
CodePudding user response：
core.eol = crlf sets crlfs on add and not on checkout
this is wrong. Working around the eol-handling limitations of toolchains you don't have is always going to be a bit of a minefield, and you've stepped on a few of them here.
git init testeol; cd $_
git config core.autocrlf false
git config core.eol crlf
echo Hello >hello.txt; git add .; git commit -m Initial
echo '* text' >.gitattributes; git add .; git commit -m .gitattributes
echo New line >>hello.txt; git commit -am 'new hello line'
So, here's a few of the mines you hit: you've told Git core.eol crlf, that you want it to work with tools that expect crlf eol's for "text", but for instance you leave hello.txt unspecified, which means you don't want eol translation done for that, but then you add an attribute that says you do want it done for that and everything else . . . but the files you add don't have crlf eol's, which means you're working with tools that don't generate and may not be expecting crlf eol's despite what your config says. So combine that with you not forcing Git to retrieve the file from the repository, and Git itself not natively using or expecting crlf eols, and, yeah. Minefield.
core.eof does crlf translation on checkout.
warning: LF will be replaced by CRLF in hello.txt.
The file will have its original line endings in your working directory
warning: LF will be replaced by CRLF in .gitattributes.
The file will have its original line endings in your working directory
on add are warning you that you added a file that has LF line endings in your work tree but your current setup is set up to replace those on checkout to your work tree with CRLF, because they're explicitly marked as text in .gitattributes and your config says you want crlf eol's in those.
But git add is not git checkout and you haven't done a checkout of those files yet, so they'll still have their original line endings in your work tree until you do that.
I think the messages could maybe be more helpful for newbies, I'm not sure exactly how. Best first guess I can come up with? Maybe that first message could read
warning: when Git writes new content to hello.txt it will replace LF with CRLF
and the second line could read
The file you added is still in the working directory, with LF line endings, unaltered.