Chrome Version: 8e7654233 (r576221)
OS: All (except perhaps Windows?)

What steps will reproduce the problem?
(1) Check out Chromium repo at 8e7654233 (r576221)
(2) git status
(3) git reset --hard
(4) git status

Note: You may need to have core.autocrlf = false in git config to trigger this bug (for some reason, it doesn't trigger for me when I change that setting). However, I created a small demo repo which *always* triggers this bug, so changing core.autocrlf seems like an unreliable workaround.

What is the expected result?
git status shows nothing dirty.
git reset --hard makes sure there is nothing dirty.
git status shows nothing dirty.

What happens instead?
git status shows

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   third_party/tcmalloc/vendor/README_windows.txt

git reset does nothing.
git status shows the same dirty file after reset.

It is impossible to do any work in git with this dirty file.

The README_windows.txt file has CRLF line endings in the tree. It is checked out with CRLF line endings in the working dir. The presence of "*.txt   text eol=lf" in .gitattributes causes it to be dirty because Git wants to convert line endings to LF.

Seems to be caused by the CQ landing two CLs within close proximity:

- r573230 -- which added the new rule "*.txt   text eol=lf" to .gitattributes, and
- r576221 -- which added README_windows.txt with CRLF line endings.

Presumably, r576221 was created (locally) before r573230, which means "git rebase" does not actually apply the line endings rule. This allowed the CQ to land the file with CRLF line endings, but all checkouts will now consider the file "modified" as it doesn't conform to the LF rule.

I've created a test case which reproduces this problem on a fresh repo:

git init
git commit --allow-empty -m "Initial commit."
git checkout -b branch
echo -e "one\ntwo" > test.txt
unix2dos test.txt
git add test.txt
git commit -m "Added test.txt [dos]"
git checkout master
echo "*.txt text eol=lf" > .gitattributes
git add .gitattributes
git commit -m "Added .gitattributes"
git checkout branch
git rebase master
git status

This is documented in "git help gitattributes":

       eol
           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. Note that
           setting this attribute on paths which are in the index with CRLF
           line endings may make the paths to be considered dirty. Adding the
           path to the index again will normalize the line endings in the
           index.

So even though this is in a third_party dir, we need to change README_windows.txt line endings to properly stop git from wanting to change this file.

Note: In my opinion, it's a mistake to set "eol=lf" in .gitattributes. This problem could happen again, if anybody somehow creates a local commit with CRLF line endings (which can happen if they have overridden core.autocrlf or core.eol, or if they cherry-pick changes from another repo, revert an old commit from before this rule, etc).