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

[Don Slutz <Don.Slutz@SierraAtlantic.com>]

On 5/14/2009 3:49 AM, Charles Bailey wrote:

> 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??).
>
>   
I have tracked this down to racy-git fix.  See 
Documentation/technical/racy-git.txt
The "randomness" is all caused by git only full checks files that could 
be racy.  And it is all related to the fact that changing core.autocrlf 
is not correctly seen by git.  I have looked at the code and adding 
filter state of the file into the index looks to be a big amount of code 
change, and it is not clear that the change is need most of the time.

I have been thinking that adding a message to "git config" when the 
value of any of the filter values (autocrlf is one of these, but there 
are more) that warns about the fact that the working tree is not changed 
and that git will report a change to files if a full recheckout is not 
done.  None of the commands "git reset --hard", "git checkout -f", and 
"git checkout-index -u -a -f" will do this by default.  The only way I 
have found so far is to do "rm .git/index;git reset --hard".
> 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.
>
>   
That is how I have changed them for v2.
   -Don


__________________________________________________________________________________________________________________
DISCLAIMER:"The information contained in this message and the attachments (if any) may be privileged and confidential and protected from disclosure. You are hereby notified that any unauthorized use, dissemination, distribution or copying of this communication, review, retransmission, or taking of any action based upon this information, by persons or entities other than the intended recipient, is strictly prohibited. If you are not the intended recipient or an employee or agent responsible for delivering this message, and have received this communication in error, please notify us immediately by replying to the message and kindly delete the original message, attachments, if any, and all its copies from your computer system. Thank you for your cooperation." 
________________________________________________________________________________________________________________