Re: [PATCH 7/8] config: add core.untrackedCache

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Dec 16, 2015, 01:10 UTC
Message-ID: <CACBZZX4joSbCTGQqN=u6FjG2V1-7T+0P+KDwZYi14a-9OQV=LQ@mail.gmail.com>
In-Reply-To: <xmqqy4cvco25.fsf@gitster.mtv.corp.google.com>

On Wed, Dec 16, 2015 at 12:03 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 16 quoted lines

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> 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.

Show 5 quoted lines

> 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.

Show 10 quoted lines

>> 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.

Show 5 quoted lines

> 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.