Re: GIT 1.6.0-rc1
- From
Alex Riesen <raa.lkml@gmail.com>
- Date
- Jul 30, 2008, 06:10 UTC
- Message-ID
- <20080730061012.GA4437@blimp.local>
- In-Reply-To
- <7vmyk0bb5r.fsf@gitster.siamese.dyndns.org>
Junio C Hamano, Wed, Jul 30, 2008 00:03:44 +0200:
Show 12 quoted lines
> Alex Riesen <raa.lkml@gmail.com> 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?
Show 11 quoted lines
> 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?