Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > Of course hindsight is 20/20, but I think that given what's been > covered in this thread it's been established that it's categorically > better that if we introduce features like these that they be > configured through the normal configuration facility rather than the > configuration being sticky to the index. I doubt that any such thing has been established at all in this thread. It may be true that you and perhaps Christian loudly repeated it, but loudly repeating something and establishing something as a fact are slightly different. 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. > Since the change in performance really isn't noticeable except on > really large repositories, which are more likely to have someone > involved watching the changelog on upgrades I think that's OK. Especially it is dubious to me that the trade-off you are making with this design is a good one. In order to avoid paying a one-time cost to run "update-index --untracked-cache" at sites that _do_ want to use that feature (and after that, if you teach "git init" and "git clone" to pay attention to the "give you the default" configuration to run it for you, so that your users won't have to), you are forcing all codepaths that makes any write to the index (not just "init"-time) to make an extra check with the configuration all the time for everybody, because you made the presence of the untracked cache data in the index not usable as a sign that the user wants to use that feature. 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. -- 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