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

[Phillip Wood <phillip.wood123@gmail.com>]

On 24/09/2026 20:24, Junio C Hamano wrote:
> 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