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

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Dec 15, 2015, 21:53 UTC
Message-ID: <CACBZZX7QW2J6DcMSXTa1y+QdMrqq5DXs1Fu3m8toV5a4yZKNjw@mail.gmail.com>
In-Reply-To: <xmqqh9jjfqk4.fsf@gitster.mtv.corp.google.com>

On Tue, Dec 15, 2015 at 8:40 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 8 quoted lines

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> I still have a problem with the approach from "design cleanliness"
> point of view[...]
>
> In any case I think we already have agreed to disagree on this
> point, so there is no use discussing it any longer from my side.  I
> am not closing the door to this series, but I am not convinced,
> either.  At least not yet.

In general the fantastic thing about the git configuration facility is that it provides both systems administrators and normal users with what they want. It's possible to configure things system-wide and override those on a user or repository basis.

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. It gives you everything that the per-index configuration gives you and more.

So assuming that's the case, how do we migrate something that's configured via the index towards being configured through git-config?

I think there's no general answer to that, but in this case the worst case scenario with accepting this series as-is is that we downgrade some users who've opted in to it to pre-v2.5.0 "git status" performance.

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.