On Tue, Dec 15, 2015 at 03:03:14PM -0800, Junio C Hamano wrote:
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
