From: Jeff King <peff@peff.net>
To: phillip.wood@dunelm.org.uk
Cc: Junio C Hamano <gitster@pobox.com>,
Harald Nordgren <haraldnordgren@gmail.com>,
ps@pks.im, git@vger.kernel.org, sandals@crustytoothpaste.net,
Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com>,
Emily Shaffer <emilyshaffer@google.com>
Subject: Re: Changing default config values (was Re: What will come after Git 2.56?)
Date: Sun, 27 Sep 2026 23:32:47 -0400 [thread overview]
Message-ID: <20260928033247.GB493672@coredump.intra.peff.net> (raw)
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
next prev parent reply other threads:[~2026-09-28 3:32 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-06 7:03 What will come after Git 2.56? Junio C Hamano
2026-09-06 18:14 ` brian m. carlson
2026-09-07 8:23 ` Patrick Steinhardt
2026-09-24 18:35 ` Harald Nordgren
2026-09-24 19:24 ` Junio C Hamano
2026-09-27 13:48 ` Changing default config values (was Re: What will come after Git 2.56?) Phillip Wood
2026-09-27 19:32 ` Junio C Hamano
2026-09-28 3:32 ` Jeff King [this message]
2026-09-25 1:20 ` What will come after Git 2.56? Kristoffer Haugsbakk
2026-09-25 16:42 ` D. Ben Knoble
2026-09-07 9:30 ` Emily Shaffer
2026-09-08 15:46 ` rsbecker
2026-09-08 15:59 ` brian m. carlson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260928033247.GB493672@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=emilyshaffer@google.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=haraldnordgren@gmail.com \
--cc=kristofferhaugsbakk@fastmail.com \
--cc=phillip.wood@dunelm.org.uk \
--cc=ps@pks.im \
--cc=sandals@crustytoothpaste.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox