Re: [PATCH 7/8] config: add core.untrackedCache
- From
Jeff King <peff@peff.net>
- Date
- Dec 16, 2015, 02:46 UTC
- Message-ID
- <20151216024605.GA618@sigill.intra.peff.net>
- In-Reply-To
- <xmqqy4cvco25.fsf@gitster.mtv.corp.google.com>
On Tue, Dec 15, 2015 at 03:03:14PM -0800, Junio C Hamano wrote:
Show 8 quoted lines
> The thing is, I do not necessarily view this as "configuration". > The way I see the feature is that you say "--untracked" when you > want the states of untracked paths be kept track of in the index, > just like you say "git add Makefile" when you want the state of > 'Makefile' be kept track of in the index. Either the index keeps > track of it, or it doesn't, based solely on user's request, and the > bit to tell us which is the case is already in the index, exactly > because that is part of the data that is kept track of in the index.
I know this is a fairly subjective argument, but it feels quite weird for me for such a config to persist in the index and not be mentioned anywhere else.
Is there any other user-specified configuration option for which:
rm -f .git/index git read-tree HEAD
will actually _lose_ information?
It seems to me that all other things being equal, we should be in favor of a config option simply because it reduces the cognitive burden on the user: it's one fewer place they need to be aware that git is keeping persistent decisions.
> If the feature is something only those with really large repositories > care about, is it a good trade-off to make everybody pay the runtime > cost and make code more complex and fragile? I am not yet convinced.
I'm not sure I understand the runtime and complexity costs of the config option. Isn't it just:
if (core_untracked_cache) {
/* do the thing */
}and loading core_untracked_cache in git_default_core_config()? Versus:
if (the_index.has_untracked_cache) {
/* do the thing */
}I ask as somebody who hasn't followed the topic closely. I just don't see what is that different about this versus other config options. What am I missing?
-Peff