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

On Tue, Dec 22, 2015 at 1:30 AM, Junio C Hamano [off-list ref] wrote:

Duy Nguyen [off-list ref] writes:

quoted

On Thu, Dec 17, 2015 at 2:44 PM, Jeff King [off-list ref] wrote:

quoted

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