On Wed, Dec 16, 2015 at 12:03 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Æ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. You probably know this, but the --untracked-cache has no bearing on what we actually keep track of, it's just an optimization for how efficiently we execute "git status" commands without the "-uno" option. We still produce the same output. > 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. What I mean by "[we've] established that it's categorically better [to do this via git-config]" is that we can still do all that stuff, we can just also do more stuff now. >> 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), It's not unreasonable to avoid the cost of running "update-index --untracked-cache", it's the difference between just adjusting /etc/gitconfig and continually having to traverse the entire / filesystem if you want to enable this feature on a system-wide basis. It should be easy to enable any Git feature via the configuration facility either on a --system, or --global or --local basis. > 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. Maybe I'm misunderstanding Christian's patches but don't we already parse the git configuration on any commands that update the index anyway? See git_default_core_config(). We already parse the git configuration to run "git status". > 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 was arguing that only users with really large repositories would notice if we turned this off because the enabling facility had changed from per-index to config. But it doesn't follow that the expense of checking the git configuration which we're parsing anyway for the index-related commands makes things more complex & fragile. -- 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