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

From: Phillip Wood <phillip.wood123@gmail.com>
Date: Sep 27, 2026, 13:48 UTC
Message-ID: <7ccc822a-6bd0-44e2-8d6b-ca525d729207@gmail.com>
In-Reply-To: <xmqqpky21mh6.fsf@gitster.g>

On 24/09/2026 20:24, Junio C Hamano wrote:

Show 13 quoted lines

> Harald Nordgren <haraldnordgren@gmail.com> writes:
> 
>> I have a list of breaking changes that I would like to introduce, I was hoping
>> they could be considered before 3.0 is out -- otherwise I fear I have to wait
>> another 10 years for 4.0, I would like to change the default values of these
>> config values:
> 
> I do not know how long it will be before 4.0, but if you do not have
> any draft code on the list or even design presented before this
> message, it is way too late for 3.0.  No, these won't be part of it.
> 
> But some may not even qualify as "breaking changes", so after 3.0,
> some of them may not have to wait until 4.0 happens.

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. Currently we tend to have a deontological approach that views any negative effect on even a small number of current users as inherently bad. A consequentialist approach would allow us more flexibility to change defaults, though we'd need some way to try and gauge the relative costs and benefits.

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. That would allow us to have a set of "modern defaults" that can evolve over time and can be easily enabled or disabled (a bit like "feature.experimental"). We may want to extend the concept slightly so that different values for "core.defaults" tune the defaults for different workflows; for example having a setting that implies "push.default=current" and "status.compareBranches=@{upstream} @{push}" for triangular workflows. If we take the approach suggested above, the modern defaults could be enabled by default and it would be easy for users to opt-out by setting a single config variable.

Thanks

Phillip