On Tue, Dec 22, 2015 at 1:30 AM, Junio C Hamano <gits...@pobox.com> wrote: > Duy Nguyen <pclo...@gmail.com> writes: > >> On Thu, Dec 17, 2015 at 2:44 PM, Jeff King <p...@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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
