From: Jeff King <peff@peff.net>
Date: Mon, 28 Sep 2026 03:32:47 GMT
Subject: Re: Changing default config values (was Re: What will come after Git 2.56?)
Message-ID: <20260928033247.GB493672@coredump.intra.peff.net>
In-Reply-To: <7ccc822a-6bd0-44e2-8d6b-ca525d729207@gmail.com>

On Sun, Sep 27, 2026 at 02:48:31PM +0100, Phillip Wood wrote:

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

I dunno. There can be some convenience in setting foo.bar that covers a
bunch of other related config options. And I'd have no objection to
feature.triangular or something that changes the fallback defaults for a
few relevant options (which could of course still be individually
overridden).

But I'm not sure what core.defaults is buying us. If I understand,
you're thinking that setting core.defaults to "modern" would give new
values for a bunch of defaults. But why wouldn't we just switch the
defaults? I can think of two reasons:

  1. It might break scripts or other automated flows. But then, so would
     config.defaults=modern (or using the individual config options
     themselves).

  2. It might anger old-timers who like the current defaults. But why
     not just switch the defaults, and let the old-timers use the
     existing config to escape-hatch back? If there's not consensus over
     the defaults, _somebody_ is going to be annoyed by whatever we
     pick.

     It's probably reasonable to pick the one that annoys the fewest
     people, though I think we instead tend to go with status quo
     inertia. Which, to be fair, is not entirely unreasonable simply
     because we don't actually _know_ what will annoy the fewest people.
     So changing nothing is often a safe guess.

-Peff