On Thu, Dec 24, 2015 at 8:56 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > >> Duy Nguyen <pclouds@xxxxxxxxx> writes: >> >>> In that case we can just check config once in read_index_from and >>> destroy UNTR extension. Or the middle ground, we check config once in >>> that place, make a note in struct index_state, and make invalidate_* >>> check that note instead of config file. The middle ground has an >>> advantage over destroying UNTR: (probably) many operations will touch >>> index but do not add or remove entries. >> >> Or we can even teach read_index_from() to skip reading the extension >> without even parsing when the configuration tells it that the >> feature is force-disabled. It can also add an empty one when the >> configuration tells it that the feature is force-enabled and there >> is no UNTR extension yet. > > Thinking about this a bit more, I am starting to feel that the > config that can be used to optionally override the presence of > in-index UNTR extension does not have to be too bad a thing, > provided if it is done with a few tweaks to the design I read in > Christian & Ævar's messages. > > One tweak is to address the following from Ævar's message: > >>> Once this series is applied and git is shipped with it existing >>> users that have set "git update-index --untracked-cache" will have >>> their UC feature disabled. This is because we fall back to "oh no >>> config here? Must have been disabled, rm it from the index" clause >>> which keeps our UC from going stale in the face of config >>> flip-flopping. > > The above would happen only if the configuration is a boolean that > defaults to false. I'd think we can have this a tristate instead. > That is, config.untrackedCache can be explicitly set to 'true', > 'false', or 'keep'. And make a missing config.untrackedCache > default to 'keep'. > > When read_index_from() reads an existing index: > > When the configuration is set to 'true': > an existing UNTR is kept, otherwise a new UNTR gets added. > When the configuration is set to 'false: > an existing UNTR is dropped. > When the configuration is set to 'keep': > an existing UNTR is kept, otherwise nothing happens. Sounds good, except.. > When write_index() writes out an index that wasn't initialized from > the filesystem, a new UNTR gets added only when the configuration is > set to 'true' and there is no in-core UNTR already. Do we really need this? If the index is created fresh from the core, first write will not have UNTR. Next time it's loaded up, UNTR is added if config is true, based on the above rules. The new UNTR extension (should?) marks the index as dirty as writing out is required. > Orthogonal to the "config overrides the existing users' practice" > issue, Yeah it looks orthogonal to me too. There should be a separate config file like /etc/gitconfig.lockdown, that will override user config vars (but we still can't undefine user config vars yet, known missing feature). -- Duy -- 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