Hello, I found out that following steps outlined in https://help.github.com/articles/dealing-with-line-endings/#refreshing-a-repository-after-changing-line-endings results in different outcomes from one execution to another, done on the same repository repeatedly:
STEPS I TOOK: 1. Comitted .gitattributes file that sets some extensions to "text eol=crlf". 2. Did repository refresh: rm -Rf * git rm --cached -r . git reset --hard 3. Expected result: files listed as "changed". Received result: sometimes it works, sometimes it doesn't: git reports "working directory clean". HOW TO REPRODUCE: 1. Clone my repository with a committed .gitattributes, but still not-refreshed files: git clone https://github.com/hageltech/msgit_test.git 2. Run this one liner while inside the git repository: for i in `seq 1 100` ; do rm -Rf * && git rm -q --cached -r . && git reset --hard -q && git status | wc -l ; done 3. You should be getting 100 lines of "71" (number of lines of output from git status), but in reality some lines will be "3", "20", etc. Git sometimes does not report all files as changed, when it should. For me, it happens with frequency of 3-5% with Git 2.2.0.rc1 on Linux, and with frequency of around 40% with 1.9.4.msysgit.2 on Windows 7, on two different machines. I initially thought this is Msysgit issue and took it to their issue tracker, where it was confirmed by other users: https://github.com/msysgit/git/issues/229 . However, it does occur with latest git version, compiled from git source, too. Best regards -- Haim Gelfenbeyn Hagel Technologies Ltd. www.hageltech.com -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
