Re: Fix extraneous lstat's in 'git checkout -f'

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 14, 2009, 08:59 UTC
Message-ID: <7vzlb7hc7y.fsf@alter.siamese.dyndns.org>
In-Reply-To: <alpine.LFD.2.01.0907132040530.13838@localhost.localdomain>

Linus Torvalds <torvalds@linux-foundation.org> writes:

> Quite frankly, I'd like for us to at least think about removing CE_VALID.

This is heavy. I personally do not use this flag, nor know anybody who does, but deviating from the original purpose of CE_VALID, which was to avoid lstat() on slow filesystems, people have advised/advocated its use for "narrow checkout". These people may not even have a file checked out to the CE_VALID path in the work tree, and they depend on us not running lstat() on them and instead always answering that the work tree has the necessary blob.

> I wonder if we have other places where we have optimized away the lstat() 
> just because we decided that it was already up-to-date - without 
> realizing that something could have been marked up-to-date just because 
> it was marked CE_VALID.

That is a very valid concern, but I think fixing them may break the "narrow checkout" people.

We may need to add ce_uptodate(ce) check instead of doing lstat() in some places (like the one you modified in this patch), not because we want to avoid lstat(), but because we do not want to lstat() paths that are marked as CE_VALID.

There are some mechanisms, such as REFRESH_REALLY flag, to give an escape hatch to break out of the CE_VALID illusion, but I have to admit that when we did CE_VALID we did not quite clarified its ramifications with respect to merging and branch switching.