git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Jeff King <peff@peff.net>
Date
Sep 28, 2026, 03:32 UTC
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:
Show 11 quoted lines
> 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
Previous: Junio C HamanoNext: Kristoffer Haugsbakk
Message 8 of 13 in “What will come after Git 2.56?”
  1. Junio C HamanoSep 6, 2026
  2. brian m. carlsonSep 6, 2026
  3. Patrick SteinhardtSep 7, 2026
  4. Harald NordgrenSep 24, 2026
  5. Junio C HamanoSep 24, 2026
  6. Changing default config values (was Re: What will come after Git 2.56?)Phillip Wood, Sep 27, 2026
  7. Junio C HamanoSep 27, 2026
  8. Jeff KingSep 28, 2026
  9. Kristoffer HaugsbakkSep 25, 2026
  10. D. Ben KnobleSep 25, 2026
  11. Emily ShafferSep 7, 2026
  12. rsbecker@nexbridge.comSep 8, 2026
  13. brian m. carlsonSep 8, 2026

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.