Jeff King <peff@xxxxxxxx> writes:
>> 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 */
> }
The latter is pretty much so, but the former needs to be a bit more
involved, e.g. more like:
if (core_untracked_cache) {
if (!the_index.has_untracked_cache)
create_and_attach_uc(&the_index);
/* do the thing */
} else {
if (the_index.has_untracked_cache)
destroy and remove untracked cache;
}
Otherwise, after adding the cache to the index, flipping the config
off, doing things with the index and working tree and then filpping
the config back on, the index would have a stale cache that does not
know what happened to the working tree while config was off, and
your "git status" will start throwing a wrong result.
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 unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html