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

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 16, 2015, 06:05 UTC
Message-ID: <xmqqoadrdj22.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <xmqqwpsfdl5y.fsf@gitster.mtv.corp.google.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 11 quoted lines

> This is why the_index.has_untracked_cache is not just a simple "Do I
> want to use this feature?" boolean configuration.  The index also
> stores the real data, and "Am I using this feature?" bit goes hand
> in hand with that real data.  Thinking that this is merely a boolean
> configuration is the real source of the confusion, and introducing a
> config that overrules what the user has stored in the index needs to
> add complexity.
>
> The additional complexity may (or may not) be justifiable, but in
> any case "all other things being equal, this is a config" feels like
> a flawed observation.

To put it another way, the "bit" in the index (i.e. the presence of the cached data) is "Am I using the feature now?". The effect of the feature has to (and is designed to) persist, as it is a cache and you do not want a stale cache to give you wrong answers. There is no "Do I want to use the feature?" preference, in other words.

And I do not mind creating such a preference bit as a configuration.

That is why I suggested such a configuration to cause the equivalent of "update-index --untracked-cache" when a new index is created from scratch (as opposed to the case where the previously created cache data is carried forward across read_cache() -> do things to the index -> write_cache() flow). Doing it that way will not have to involve additional complexity that comes from the desire that setting a single configuration on (or off) has to suddenly change the behaviour of an index file that is already using (or not using) the feature.