On Tue, May 12, 2009 at 10:48:03PM -0400, Don Slutz wrote: > This both works and fails with either file2 & subdir/file3 "modified" or > just subdir/file3. I have found that "git reset --hard" looks to be the > issue. If you have autocrlf=true, and a clean work tree and then set > autocrlf=false; then > "git reset --hard" does not change the work tree files. However > sometimes (which so far I have only been able to reproduce with this > test) git diff will report the difference. It shouldn't be random. git reset --hard should only reset those working tree files for which the appropriate index entry has been change or which have been change on disk since checkout from the index. Changing the core.autocrlf setting doesn't count as in index change (although perhaps it should??). The point of git reset --hard in these tests was to throw away any uncommitted merge resolutions and/or conflicts, not about rechecking out everything. Admittedly the tests are probably a bit fast and loose and they should probably force a complete refresh from the index when the core.autocrlf setting is changed. -- Charles Bailey http://ccgi.hashpling.plus.com/blog/ -- 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