Re: [PATCH 7/8] config: add core.untrackedCache

From: Duy Nguyen <pclouds@gmail.com>
Date: Dec 22, 2015, 08:27 UTC
Message-ID: <CACsJy8AF-7ULixapHmTtCia9x0HTtJ1nmnAER9A3BeLVjQM_Mg@mail.gmail.com>
In-Reply-To: <xmqqy4cnfyds.fsf@gitster.mtv.corp.google.com>

On Tue, Dec 22, 2015 at 1:30 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 22 quoted lines

> Duy Nguyen <pclouds@gmail.com> writes:
>
>> On Thu, Dec 17, 2015 at 2:44 PM, Jeff King <peff@peff.net> wrote:
>>> I think we may actually be thinking of the same thing. Naively, I would
>>> expect:
>>>
>>> ..
>>>   - if there is cache data in the index but that config flag is not set,
>>>     presumably we would not update it (we could even explicitly drop it,
>>>     but my understanding is that is not necessary for correctness, but
>>>     only as a possible optimization).
>>
>> No, if somebody adds or removes something from the index, we either
>> update or drop it, or it's stale. There's the invalidate_untracked()
>> or something in dir.c that we can hook in, check config var and do
>> that. And because config is cached recently, it should be a cheap
>> operation.
>
> Checking the config may be cheap, but it bothers me a lot that we
> have to call that "invalidate" thing every time we go into the
> codepath to deal with the index, from code cleanliness point of
> view.

In that case we can just check config once in read_index_from and destroy UNTR extension. Or the middle ground, we check config once in that place, make a note in struct index_state, and make invalidate_* check that note instead of config file. The middle ground has an advantage over destroying UNTR: (probably) many operations will touch index but do not add or remove entries. Though I may be wrong, replacing an entry may be implemented as delete then add, I haven't checked the code.

-- 
Duy