Subject: Re: Random failure after "git config core.autocrlf false" then "git reset --hard"

From: Charles Bailey <[email-masked]>
Date: Thu, 14 May 2009 08:49:25 +0100

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/