Git line ending trouble

[Dennis van der Wal <d.vanderwal@comparegroup.eu>]

Hello everyone,

Recently we have migrated from Subversion to Git in a multiplatform,
though mostly Windows oriented working environment. During the course of
this migration we ran into newline issues between people using Mac and
Windows. When investigating the issue we noticed that the migration
process had created many entries in the .gitattributes like "path/to/file
-text", explaining the problem.

To fix this problem we tried cleaning up the .gitattributes file and then
re-adding the files to Git so they would be stored with LF type line
endings (https://help.github.com/articles/dealing-with-line-endings). This
seemed to work until I noticed some weird behaviour, namely that whenever
I executed the aforementioned steps the number of files changed would
differ.

To verify this observation I tried the following experiment. I cloned one
of the migrated repositories 4 times, each of them cloned cleanly into a
different directory. Then for each, on master, I executed the following
commands:
  echo "* text=auto" > .gitattributes
  git add .
  git commit -m "Create basic .gitattributes file."
  git rm -r --cached .
  git reset --hard
  git add .
  git commit -m "Normalise line endings."
Note that the .gitattributes used to consist of one line "* text=auto
!eol" and many of the "path/to/file -text" entries I mentioned before, but
now has all content replaced with "* text=auto".

Each time the second commit command yielded a different result, ranging
from 0 files changed to 738 files changed and most of them hovering around
the 500+ mark. I tried with both version 1.7.12.4 and 1.8.4 on Mac OSX
Mountain Lion (10.8.5).

So my question to this mailing list is: Is this deviation in number of
files changed a known problem and if so is there a known workaround? I
tried looking for this particular observation, but I found it hard to come
up with a search query describing this issue.

Sincerely,
Dennis van der Wal
Java Developer at Compare Group