Junio C Hamano <gitster@xxxxxxxxx> writes: > 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 put it another way, the "bit" in the index (i.e. the presence of the cached data) is "Am I using the feature now?". The effect of the feature has to (and is designed to) persist, as it is a cache and you do not want a stale cache to give you wrong answers. There is no "Do I want to use the feature?" preference, in other words. And I do not mind creating such a preference bit as a configuration. That is why I suggested such a configuration to cause the equivalent of "update-index --untracked-cache" when a new index is created from scratch (as opposed to the case where the previously created cache data is carried forward across read_cache() -> do things to the index -> write_cache() flow). Doing it that way will not have to involve additional complexity that comes from the desire that setting a single configuration on (or off) has to suddenly change the behaviour of an index file that is already using (or not using) the feature. -- 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