git line endings - can't stash, reset and now can't rebase over spurious line endings commit

Question

I have a repo I added a gitattributes to it and was working on it fine. I sync it via dropbox to another machine. When I opened it to the other machine a bunch

Answer 1

Have you tried this?

git add -u .
git reset

Answer 2

None of this works on my Windows 10 WSL, I had diff in README.md and was not able to pull changes, so I've did this from

echo README.md >> .gitignore # not sure if this is needed
rm README.md # this need to be rm without git
git pull
git checkout .gitignore # to remove the change

I think that it will also work if you just do:

rm file
git checkout <branch>

but I'm not able to test because my repo is working now.

Answer 3

We ran into this issue today where it seemed the problem stemmed from some CRLF-related issues related to a newly added .gitattributes file with a single line * text=auto. When you rebased or created a new branch, said file would follow you and ruin any changes that came after along with preventing you from leaving that branch without first committing it.

We initially fixed this by checking out a temporary branch, reverting the file back to a sane state (before modifications), committing and then doing a rebase on the entire branch back to the oldest commit to make it look like master. That worked for a while but a similar file popped up after that and the same fix didn't work again.

What we eventually went with was similar to what op shared in his update.. a single line inside .git/info/attributes with file-to-remove -text seems to mitigate the problem. I say mitigate because I'm not sure if there are any adverse implications to doing this, this was also for one file so might not work as well if at all.

Answer 4

Finally after 5 years here is a complete answer, thanks to Torsten Bögershausen.

The way to debug this eol situation is to investigate using the --eol switch to git ls-files added by Torsten Bögershausen. Turns out that the file(s) in question were committed with CRLF while the .gitattributes file added later specified text for these files. This results in an "illegal state". Nothing to be done, for old commits.

What should be done is git add --renormalize . so the files are added with correct (lf) line endings and then reset --hard to have those lineendings in the working tree.

Now this won't help with old commits, however (the commits that are in this illegal state, so between the files were committed with wrong line endings and the gitattributes commit) - checking those out will probably lead to those unresetable changes. The fix for this is provided by the answer by @iKlsR:

$ cat .git/info/attributes
"Mopy/Docs/Bash Readme Template.html" -text

the reason being that:

When deciding what attributes are assigned to a path, Git consults $GIT_DIR/info/attributes file (which has the highest precedence), .gitattributes file in the same directory as the path in question, and its parent directories up to the toplevel of the work tree [ect]

(emphasis mine)

Just be sure to add the line after you renormalise, otherwise the file(s) won't be added to the renormalise commit!

Answer 5

Same issue here, I am using Win7, sourceTree v3.0.9, git v1.9.5

In repo root, when .gitattribute file has text=auto, it shows a lot of local file changes about line ending and it prevents me from doing anything. After I set text=crlf, all local changes are gone.

Previously I tried to adding "[core] autocrlf = false" in config file, but it didn't help.

Updated on 12/06/2018: My SourceTree was using embedded git with old version, just update it in SourceTree and everything works now with "text=auto" in .gitattributes

Answer 6

The same issue happened with me today. Try this

git config --local core.fileMode false

as discussed here: How do I make Git ignore file mode (chmod) changes?