Cannot checkout after setting the eol attribute

Hi,

I specified the eol attribute on some files recently and the behavior of Git is very strange.

Here is the set of commands to set up the repository used for the discussion:

git init
echo $'dos\r' > dos
git add dos
git commit -m "dos newlines"
echo "dos -crlf" > .gitattributes
git add .gitattributes
git commit -m "add attributes"
echo "dos eol=crlf" > .gitattributes
git add .gitattributes
git commit -m "set eol attribute instead"

The following behaviors are observed:

- git reset --hard does not make the working directory clean; and
- git rebase gets *very* confused about the diffs in the working

    tree because `git stash` can't reset the working tree;

There are probably other oddities lingering about as well. If I commit what Git thinks is the difference, the diff (with invisibles made visible) is:

    % git diff | cat -A
    diff --git a/dos b/dos$
    index fde2310..4723a1b 100644$
    --- a/dos$
    +++ b/dos$
    @@ -1 +1 @@$
    -dos^M$
    +dos$

Seen in 2.9.5 and 2.14.0.rc1.

--Ben

When you set the text attribute (in your case "eol=crlf" implies text) then the file(s) -must- be nomalized and commited so that they have LF in the repo (technically speaking the index)

This is what is written about the "eol=crlf" attribute:
This setting forces Git to normalize line endings for this file on checkin and convert them to CRLF when the file is checked out.
And this is what is implemented in Git.

Long story short:

The following would solve your problem:
git init
echo $'dos\r' > dos
git add dos
git commit -m "dos newlines"
echo "dos -crlf" > .gitattributes
git add .gitattributes
git commit -m "add attributes"
echo "dos eol=crlf" > .gitattributes
git read-tree --empty # Clean index, force re-scan of working directory

Quoted 3 lines · Torsten Bögershausen

When you set the text attribute (in your case "eol=crlf" implies text) then the file(s) -must- be nomalized and commited so that they have LF in the repo (technically speaking the index)

This seems like a special case that Git could detect and message about somehow.

Quoted 5 lines

This is what is written about the "eol=crlf" attribute:
This setting forces Git to normalize line endings for this file on checkin and convert them to CRLF when the file is checked out.
And this is what is implemented in Git.

Yeah, I read the docs, but the oddities of reset not doing its job wasn't clear from this sentence :) .

Quoted 13 lines

Long story short:

The following would solve your problem:
git init
echo $'dos\r' > dos
git add dos
git commit -m "dos newlines"
echo "dos -crlf" > .gitattributes
git add .gitattributes
git commit -m "add attributes"
echo "dos eol=crlf" > .gitattributes
git read-tree --empty # Clean index, force re-scan of working directory

The fact that plumbing is necessary to dig yourself out of a hole of the eol attribute changes points to something needing to be changed, even if it's only documentation. Could Git detect this and message about it somehow when git reset cannot fix the working tree?

Or maybe it could at least exit with failure instead of success?

git reset does it's job - please see below.

The problem is that we need a "git commit" here.
After applying .gitattributes, it may be neccessary to "normalize" the files. If there is something in the documentation, that can be improved, please let us know.

Quoted 4 lines

The fact that plumbing is necessary to dig yourself out of a hole of the eol attribute changes points to something needing to be changed, even if it's only documentation. Could Git detect this and message about it somehow when git reset cannot fix the working tree?

The thing is, that the working tree is "in a good state":
We want "dos" with CRLF, and that is what we have.
There is nothing that can be improved in the working tree. What needs to be fixed, is the index. And that needs to be done with "git add" "git commit."
As Junio pointed out, the read-tree is not ideal
(to fix a single file in a possible dirty working tree)

In your case it looks like this:

    echo "dos eol=crlf" > .gitattributes
    git add .gitattributes &&
    git rm --cached dos && git add dos &&
    git commit

Quoted 1 line

Or maybe it could at least exit with failure instead of success?

I don't know.
It -may- be possible to add a warning in "git reset". I can have a look at that...

The following would solve your problem:
git init
echo $'dos\r' > dos
git add dos
git commit -m "dos newlines"
echo "dos -crlf" > .gitattributes
git add .gitattributes
git commit -m "add attributes"
echo "dos eol=crlf" > .gitattributes

git read-tree --empty # Clean index, force re-scan of working directory
git add dos

git add .gitattributes
git commit -m "set eol attribute instead"
git ls-files --eol

When setting the eol attribute, paths can change their dirty status without any change in the working directory. This can cause confusion and should at least be mentioned with a remedy.

Signed-off-by Ben Boeckel <[email protected]>

---
 Documentation/gitattributes.txt | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

Documentation/gitattributes.txt +0 -0

index c4f2be2..3044b71 100644

This attribute sets a specific line-ending style to be used in the working directory. It enables end-of-line conversion without any
-content checks, effectively setting the text attribute. +content checks, effectively setting the text attribute. Note that +setting this attribute on paths which are in the index with CRLF +line endings makes the paths to be considered dirty. +Adding the path to the index again will normalize the line +endings in the index.

How about something like this :

This attribute sets a specific line-ending style to be used in the working directory. It enables end-of-line conversion without any
-content checks, effectively setting the text attribute. +content checks, effectively setting the text attribute. Note that +setting this attribute on paths which are in the index with CRLF +line endings makes the paths to be considered dirty.

Is this "always makes them dirty" or "may make them dirty depending on the situation"?

If the latter, I'd prefer to see s/makes/may make/ here.