Why is the following command inconsistent in my repository?

Question

In my repository, which has mixed line endings. I am using Mac OS X, and git 1.8.3.1

I would like to renormalize this repository so that every file has line endings that agree with the .gitattributes file.

To this end, I have checked out the latest change:

git checkout origin/develop
git reset --hard
git rm -rf .
git rm --cached -rf .
rm .git/index
git checkout HEAD .gitattributes
git reset --hard
git status

Now, git rm --cached -rf . will cause an error, but I am being very paranoid with the above command. (On my machine, those commands were on one line, ignoring exit codes)

I repeat the command many times. (Ie, UP; ENTER; UP; ENTER; UP; ENTER;...)

Most of the time, I have a clean check out, which is not what I am expecting.

However, roughly once every ten times, I find that I get three files (which seem to be correctly renormalized). The remaining times there is no renormalization.

The output of such a file that gets renormalized (Ie, is 'modified') is:

$ file source/RemoveDuplications.cs
source/RemoveDuplications.cs: UTF-8 Unicode (with BOM) C++ program text, with CRLF line terminators

My git attributes file has a fair number of entries, but the relevant one is here:

* text=auto
*.cs text eol=crlf

What might be going wrong here?

Answer 1

It looks like what you are doing may be overly complex. You shouldn't need to remove all files from the repo or delete the index by hand. Have you tried:

git rm --cached -r .  # remove everything from the index
git reset --hard      # replace files w/ corrected line endings
git add .             # stage all changes
git commit -m "Normalize line endings"

If this isn't working for you I'd re-check the values of your core.autocrlf and .gitattributes. You may need to clear those, reset your shell, check out the repo again and then reset them to get the behavior you want.

Here are some other resources that might help:

• Github - dealing w/ line endings
• A similar question here with multiple answers to consider
• A good post about the pros/cons of this approach vs git filter-branch