git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: "Thomas Weißschuh" <thomas@t-8ch.de>,
	git@vger.kernel.org,
	"Johannes Schindelin" <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH v2] var: add GIT_DEFAULT_BRANCH variable
Date: Wed, 3 Nov 2021 07:37:13 -0400	[thread overview]
Message-ID: <YYJ0aQ11uHA/XUt3@coredump.intra.peff.net> (raw)
In-Reply-To: <211102.86czni1o72.gmgdl@evledraar.gmail.com>

On Tue, Nov 02, 2021 at 05:53:46PM +0100, Ævar Arnfjörð Bjarmason wrote:

> The reason I suggested extending "git config" in [1] is because it seems
> like a natural thing for "git config" to learn to spew out our idea of
> default hardcoded config values to the user.
> 
> But creating a variable form of that existing config just so we can have
> "git var" spew it out just seems weird.
> 
> We don't have or need such a variable now for anything else, so why go
> through that indirection, instead of something that closes the feature
> gap of asking what a config variable default is?

To me, the point is that the user is not asking "what is the default
value of this config variable?". They are asking "if I were to init a
new repository, what would Git decide the default branch name is?".

Right now that is very tied to the config mechanism (modulo the
GIT_TEST_* bits, but I think we can ignore those for regular users), so
those two are basically the same question. But it doesn't have to be.
Abstracting it to the question the user actually wants to ask
future-proofs the mechanism.

I.e., I don't think introducing a new variable into "git var" is that
big a deal. They don't have to be related to an environment variable;
the documentation calls them "logical variables". This is exactly the
kind of thing it's designed for.

-Peff

  parent reply	other threads:[~2021-11-03 11:37 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-30 14:01 [PATCH] builtin: add git-default-branch command Thomas Weißschuh
2021-10-30 17:18 ` Ævar Arnfjörð Bjarmason
2021-11-02 13:39 ` Johannes Schindelin
2021-11-02 16:44   ` [PATCH v2] var: add GIT_DEFAULT_BRANCH variable Thomas Weißschuh
2021-11-02 16:53     ` Ævar Arnfjörð Bjarmason
2021-11-02 17:35       ` Thomas Weißschuh
2021-11-02 19:14         ` Ævar Arnfjörð Bjarmason
2021-11-02 20:08           ` Thomas Weißschuh
2021-11-03 11:37       ` Jeff King [this message]
2021-11-03 16:48         ` Eric Sunshine
2021-11-03 18:21     ` Junio C Hamano
2021-11-03 18:53       ` [PATCH v3] " Thomas Weißschuh
2021-11-03 19:57         ` Eric Sunshine
2021-11-03 20:04           ` Junio C Hamano
2021-11-03 20:17           ` [PATCH v4] " Thomas Weißschuh
2021-11-03 20:23             ` Junio C Hamano
2021-11-03 17:22   ` [PATCH] builtin: add git-default-branch command Junio C Hamano
2021-11-03 23:44     ` Johannes Schindelin

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=YYJ0aQ11uHA/XUt3@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=thomas@t-8ch.de \
    /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;
as well as URLs for NNTP newsgroup(s).