Re: Changing default config values (was Re: What will come after Git 2.56?)

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 27, 2026, 19:32 UTC
Message-ID: <xmqqfqyuqymd.fsf@gitster.g>
In-Reply-To: <7ccc822a-6bd0-44e2-8d6b-ca525d729207@gmail.com>

Phillip Wood <phillip.wood123@gmail.com> writes:

Show 8 quoted lines

> A couple of thoughts about changing the default values for config variables:
>
> For ui related config values such as diff.algorithm, diff.colorWords, 
> commit.verbose, merge.conflictStyle etc. where their effect is largely 
> cosmetic and the potential negative impact of the value changing is 
> limited, I wonder if we should be more willing to take a 
> consequentialist approach and allow changes where the net benefit 
> outweighs any potential downside.

I think we are already doing that (We've already changed the default merge strategy at least twice, for example), but the thing is, "net benefit" and "potential downside" are both mere speculations until you actually release such a change and wait for months to see distros deliver the change to their users.

> One way we could change the default values of a set of config variables 
> is to have a config variable, say "core.defaults", that determines the 
> default values of the config variables we'd like to change.

You'd need a way to poll the value of core.defaults to see the population distribution to see how beneficial the proposed update is, but then wouldn't it be easier to measure on the target configuration itself? How big a population cares enough to bother setting diff.algorithm to value X? Multiply it by 3 and you may get a rough approximation of how much of your entire population would love to live in a hypothetical world where algorithm X were the default.