Alex Riesen <raa.lkml@xxxxxxxxx> writes: > Junio C Hamano, Wed, Jul 30, 2008 00:03:44 +0200: >> Alex Riesen <raa.lkml@xxxxxxxxx> writes: >> >> Alex, I ran the full test with this, but only on Linux boxes; obviously >> >> not on any flavor of Windows. I think it is correct, and the "first line >> >> of defence" fix is the same as your patch, so I'd assume it would work for >> >> you as well. But extra eyeballs are always appreciated. >> > >> > Well, it works on Cygwin too. And I had my eyeballs on the code >> > (wondered first if it will cause more fs accesses than before: it >> > will, in the racy check. Which is correct, AFAICT) >> >> I thought racy check won't even trigger for gitlinks, no? >> > > I didn't know. But now, come to think of it, there wouldn't be much > point - the gitlinks are always compared by content, aren't they? > >> ce_modified_check_fs() has 3 call sites: >> >> - the call site in ie_match_stat() is protected with is_racy_timestamp() >> that is always false for gitlinks; >> >> - the call site in ie_modified() we just took care of in the current >> thread; >> >> - the other call site is in ce_smudge_racily_clean_entry(), which is >> called from write_index() but it also is protected with >> is_racy_timestamp() that is always false for gitlinks. > > So, the change in ce_modified_check_fs is not really needed, because > the gitlink case is never executed? That's what I meant by "futureproofing". -- 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
