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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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." ________________________________________________________________________________________________________________
--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]