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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html