Christian Couder <christian.couder@xxxxxxxxx> writes: > In fact "git update-index --[no-|force-]untracked-cache" is very bad > because it means that two repositories can be configured differently > even if they have the same config files. If you stop thinking that "update-index --untracked-cache" is somehow a "configuration", things will get clearer to you. Imagine there is no configuration whatsoever. The index primarily keeps track of what will be in the next "write-tree", but optionally it can keep track of other kinds of information, such as the last unmerged states for paths whose conflicts have been resolved. Duy's work adds another kind of information to the mix--cached stat bits for untracked paths to speed up the next "git status", and the option is to start keeping track of that information in the index. Because it is a "cache", once you start keeping track of it, you need to maintain it--otherwise you will be fooled by stale information still in the cache. So of course the effect has to persist. There is nothing _wrong_ with that. If you want to stop maintaining it, you can tell the index "don't use untracked-cache". So I think the above "is very bad because" is total nonsense. > If you want only some repos to use the UC, you will set > core.untrackedCache in the repo config. Then after cloning such a > repo, you will copy the config file, and this will not be enough to > enable the UC. Surely. "Does this index file keeps track of the untracked files' states?" is a property of the index. Cloning does not propagate the configuration and copying or not copying is irrelevant. If you want to enable, running "update-index --untracked-cache" is a way to do so. I cannot see what's so hard about it. > And if you have set core.untrackedCache in the global config when you > clone, UC is enabled, but if you have just set it in the repo config > after the clone, it is not enabled. That's fine. In your patch series, if you set it in the global, you will get the cache in the new one. With the cleaned-up semantics I suggested, the same thing will happen. And with the cleaned-up semantics, the configuration is *ONLY* used to give the *DEFAULT* before other things happen, i.e. creation of the index file for the first time. Because the configuration is only the default, an explicit "update-index --[no-]untracked-cache" will defeat it, just like any other config/option interaction. The biggest issue I had with your patch series, IIRC, is that configuration will defeat the command line option. > Shouldn't it be nice if they could just enable core.untrackedCache in > the global config files without having to also cd into every repo and > use "git update-index --untracked-cache" there? NO. It is bad to change the behaviour behind users' back. Set that once, _future_ repositories their users will create will use that by default, and tell their users what to do to their existing repositories. Problem solved. > "git update-index --[no-|force-]untracked-cache" is a bad way, so > let's make it easy for people to not use it at all. As I disagree with that basic premise, I have to disagree with the conclusion as well. -- 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