Git development
 help / color / mirror / Atom feed
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

  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