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

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 14, 2015, 21:30 UTC
Message-ID: <xmqqa8pciuqq.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <xmqq6100ke7v.fsf@gitster.mtv.corp.google.com>

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

Show 8 quoted lines

> If you stop thinking that "update-index --untracked-cache" is
> somehow a "configuration", things will get clearer to you.
> ...
>> "git update-index --[no-|force-]untracked-cache" is a bad way, so
>> let's make it easy for people to not use it at all.
>
> As I disagree with that basic premise, I have to disagree with the
> conclusion as well.

Having said all that, I do not think an option to "update-index" must be the _only_ interface to tell the index to use (or ignore) the untracked cache. Two obvious places that can also have the same command line option would be "git init" and "git clone". If either the per-user configuration (or the per-site one the administrator sets) gave the default for these two commands, that would make it unnecessary to use "update-index", unless you are experimenting or working around bugs in the implementation.

The primary reason why I do not like your "configuration decides" is it will be a huge source of confusions and bugs. Imagine what should happen in this sequence, and when should a stale cached information be discarded?

 - the configuration is set to 'yes'.
 - the index is updated and written by various commands.
 - more work is done in the working tree without updating the index.
 - the configuration is set to 'no'.
 - more work is done in the working tree without updating the index.
 - the configuration is set to 'yes'.
 - more work is done in the working tree without updating the index.
 - somebody asks "what untracked paths are there?"

In the "configuration decides" world, I am not sure how a sane implementation efficiently invalidates the cache as needed, without the config subsystem having intimate knowledge with the untracked cache (so far, the config subsystem is merely a key-value store and does not care _what_ it stores; you would want to invalidate the cache in the index when somebody sets the variable to 'no', which means the config subsystem needs to know that this variable is special).