Re: git reset for index restoration?

From: Junio C Hamano <gitster@pobox.com>
Date: May 22, 2014, 21:58 UTC
Message-ID: <xmqqd2f5mq5h.fsf@gitster.dls.corp.google.com>
In-Reply-To: <1400795586.18134.40.camel@stross>

David Turner <dturner@twopensource.com> writes:

Show 21 quoted lines

> On Thu, 2014-05-22 at 14:34 -0700, Junio C Hamano wrote:
>> Jeff King <peff@peff.net> writes:
>> 
>> > [+cc Junio for cache-tree expertise]
>> > ...
>> > We never call reset_index now, because we handle it via diff.  We could
>> > call prime_cache_tree in this case, but I'm not sure if that is a good
>> > idea, because it primes it from scratch (and so it opens up all those
>> > trees that we are trying to avoid touching). I'm not sure if there's an
>> > easy way to update it incrementally; I don't know the cache-tree code
>> > very well.
>> 
>> The cache-tree is designed to start in a well-populated state,
>> allowing you to efficiently smudge the part you touched by
>> invalidating while keeping the parts you haven't touched intact.
>
> As far as I can tell, the cache-tree does not in fact ever get into a
> well-populated state (that is, it does not exist at all) under ordinary
> git operation except by git reset --hard.  Perhaps this was already
> clear from the previous traffic on the thread, but I wanted to make sure
> Junio was also aware of this.

Yes. As I said, that should not usually be a problem for those who do the real work (read: commit), at which time write-tree will fully populate the cache-tree.