Alex Riesen <raa.lkml@xxxxxxxxx> writes: > Johannes Schindelin, Mon, Jul 21, 2008 20:20:43 +0200: >> Hi, >> >> On Mon, 21 Jul 2008, Alex Riesen wrote: >> >> > For example - Cygwin. >> >> Please enhance: your oneline is too long, and your commit message body too >> short. > > Well, I'm really not sure. I just found this difference between linux > and cygwin (st_stat is 0 for dirs on cygwin). Than I noticed that the > routine where I made the change explicitely checks for st_size not > being 0. I must admit I can't make much out of comment, and hope this > discussion will help to clear the check up. The cached stat information in the index is used to speed up comparison between "the last staged data" and what is in the working tree. ie_match_stat() compares ce_xxx fields with the result from lstat(2) we just did, and if there are differences, we take it as a sign that what's in the working tree is different from what we saw when we updated the index entry. But there is a twist. Ordinarily, when an entry enteres the index, the hash of the blob contents goes along with the lstat(2) information taken from the file that supplied the contents. However there are some cases we populate the index without lstat(2). update-index --cacheinfo, update-index --index-info are two examples, and when they add index entries, they leave ce_size field to zero. ie_match_stat() will compare that zero ce_size with the size information obtained from the working tree, and declare (falsely) that "what's in the working tree is different -- it can never match, and there is no point trying to re-index to see if they actually match", even though the reason ce_size is zero is *not* because we observed the size of the working tree file *was* zero when we indexed it the last time (it is zero merely because we haven't looked at it yet). The ce_modified_check_fs() call is there to deal with this "we cannot trust the ce_xxx fields" case. I however have to wonder if you also need to touch the end of ce_match_stat_basic() that checks for zero sized cache entry. -- 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
