[PATCH] builtin: add git-default-branch command

Introduce command `default-branch` which allows to retrieve the branch
that will be used by git-init.

Currently this command is equivalent to
	git config init.defaultbranch || 'master'

This however will break if at one point the default branch is changed as
indicated by `default_branch_name_advice` in `refs.c`.

By providing this command ahead of time users of git can make their
code forward-compatible.

Signed-off-by: Thomas Weißschuh <redacted>
---
 .gitignore                           |  1 +
 Documentation/git-default-branch.txt | 15 +++++++++++++
 Makefile                             |  1 +
 builtin.h                            |  1 +
 builtin/default-branch.c             | 33 ++++++++++++++++++++++++++++
 command-list.txt                     |  1 +
 git.c                                |  1 +
 t/t1417-default-branch.sh            | 21 ++++++++++++++++++
 8 files changed, 74 insertions(+)
 create mode 100644 Documentation/git-default-branch.txt
 create mode 100644 builtin/default-branch.c
 create mode 100755 t/t1417-default-branch.sh

diff --git a/.gitignore b/.gitignore
index 311841f9be..d9b969dc7e 100644
--- a/.gitignore
+++ b/.gitignore

@@ -53,6 +53,7 @@
 /git-cvsimport
 /git-cvsserver
 /git-daemon
+/git-default-branch
 /git-diff
 /git-diff-files
 /git-diff-index

diff --git a/Documentation/git-default-branch.txt b/Documentation/git-default-branch.txt
new file mode 100644
index 0000000000..d5b891e5b4
--- /dev/null
+++ b/Documentation/git-default-branch.txt

@@ -0,0 +1,15 @@
+git-default-branch(1)
+===================
+
+NAME
+----
+git-default-branch - Read the default branch ref used by git
+
+SYNOPSIS
+--------
+[verse]
+'git default-branch'
+
+GIT
+---
+Part of the linkgit:git[1] suite

diff --git a/Makefile b/Makefile
index d1feab008f..49276359ab 100644
--- a/Makefile
+++ b/Makefile

@@ -1091,6 +1091,7 @@ BUILTIN_OBJS += builtin/credential-cache.o
 BUILTIN_OBJS += builtin/credential-store.o
 BUILTIN_OBJS += builtin/credential.o
 BUILTIN_OBJS += builtin/describe.o
+BUILTIN_OBJS += builtin/default-branch.o
 BUILTIN_OBJS += builtin/diff-files.o
 BUILTIN_OBJS += builtin/diff-index.o
 BUILTIN_OBJS += builtin/diff-tree.o

diff --git a/builtin.h b/builtin.h
index 16ecd5586f..65b41e4c1f 100644
--- a/builtin.h
+++ b/builtin.h

@@ -143,6 +143,7 @@ int cmd_credential(int argc, const char **argv, const char *prefix);
 int cmd_credential_cache(int argc, const char **argv, const char *prefix);
 int cmd_credential_cache_daemon(int argc, const char **argv, const char *prefix);
 int cmd_credential_store(int argc, const char **argv, const char *prefix);
+int cmd_default_branch(int argc, const char **argv, const char *prefix);
 int cmd_describe(int argc, const char **argv, const char *prefix);
 int cmd_diff_files(int argc, const char **argv, const char *prefix);
 int cmd_diff_index(int argc, const char **argv, const char *prefix);

diff --git a/builtin/default-branch.c b/builtin/default-branch.c
new file mode 100644
index 0000000000..e74c078926
--- /dev/null
+++ b/builtin/default-branch.c

@@ -0,0 +1,33 @@
+#include "builtin.h"
+#include "config.h"
+#include "refs.h"
+#include "parse-options.h"
+
+static const char * const git_default_branch_usage[] = {
+	N_("git default-branch"),
+	NULL
+};
+
+
+int cmd_default_branch(int argc, const char **argv, const char *prefix)
+{
+	char *name;
+
+	struct option options[] = {
+		OPT_END(),
+	};
+
+	argc = parse_options(argc, argv, prefix, options,
+			     git_default_branch_usage, 0);
+
+	if (argc != 0)
+		usage_with_options(git_default_branch_usage, options);
+
+	name = repo_default_branch_name(the_repository, 1);
+
+	if (!name)
+		die("Could not fetch default branch name");
+
+	puts(name);
+	return 0;
+}

diff --git a/command-list.txt b/command-list.txt
index a289f09ed6..950fa9a993 100644
--- a/command-list.txt
+++ b/command-list.txt

@@ -81,6 +81,7 @@ git-cvsexportcommit                     foreignscminterface
 git-cvsimport                           foreignscminterface
 git-cvsserver                           foreignscminterface
 git-daemon                              synchingrepositories
+git-default-branch                      plumbinginterrogators
 git-describe                            mainporcelain
 git-diff                                mainporcelain           info
 git-diff-files                          plumbinginterrogators

diff --git a/git.c b/git.c
index 18bed9a996..112f37a7f3 100644
--- a/git.c
+++ b/git.c

@@ -516,6 +516,7 @@ static struct cmd_struct commands[] = {
 	{ "credential-cache", cmd_credential_cache },
 	{ "credential-cache--daemon", cmd_credential_cache_daemon },
 	{ "credential-store", cmd_credential_store },
+	{ "default-branch", cmd_default_branch, RUN_SETUP_GENTLY },
 	{ "describe", cmd_describe, RUN_SETUP },
 	{ "diff", cmd_diff, NO_PARSEOPT },
 	{ "diff-files", cmd_diff_files, RUN_SETUP | NEED_WORK_TREE | NO_PARSEOPT },

diff --git a/t/t1417-default-branch.sh b/t/t1417-default-branch.sh
new file mode 100755
index 0000000000..d81f1ee214
--- /dev/null
+++ b/t/t1417-default-branch.sh

@@ -0,0 +1,21 @@
+#!/bin/sh
+
+test_description='Test git default-branch'
+
+. ./test-lib.sh
+
+unset GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
+
+test_expect_success 'without configuration' '
+	b=$(git default-branch) &&
+	verbose test "$b" = master
+'
+
+test_expect_success 'with configuration' '
+	git config init.defaultbranch foo &&
+	b=$(git default-branch) &&
+	echo $b &&
+	verbose test "$b" = foo
+'
+
+test_done

base-commit: 6c40894d2466d4e7fddc047a05116aa9d14712ee
-- 
2.33.1

On Sat, Oct 30 2021, Thomas Weißschuh wrote:

Introduce command `default-branch` which allows to retrieve the branch
that will be used by git-init.

Currently this command is equivalent to
	git config init.defaultbranch || 'master'

This however will break if at one point the default branch is changed as
indicated by `default_branch_name_advice` in `refs.c`.

By providing this command ahead of time users of git can make their
code forward-compatible.

Recently there was a discussion on a similar topic, i.e. to have git
explicitly aware of "default config" as far as "git config -l" etc. go:

    https://lore.kernel.org/git/87czvoowg2.fsf@evledraar.gmail.com/

I'd much rather see as add this as some mode of git-config, even if it's
a new --get-or-git-default switch:

    git config --get-or-git-default init.defaultBranch

That would just currently die if you fed it any other value than
init.defaultBranch, i.e. that (or similar) would be a generic enough
interface that we could expand on it.

Whereas having a new-built in just for this one config variable...

+test_expect_success 'without configuration' '
+	b=$(git default-branch) &&
+	verbose test "$b" = master
+'
+
+test_expect_success 'with configuration' '
+	git config init.defaultbranch foo &&
+	b=$(git default-branch) &&
+	echo $b &&
+	verbose test "$b" = foo
+'
+

Should lose the echo, and these comparisons should be using test_cmp,
also use "test_config" not "git config" unless in a sub-repo or similar.

Hi Thomas,

On Sat, 30 Oct 2021, Thomas Weißschuh wrote:

Introduce command `default-branch` which allows to retrieve the branch
that will be used by git-init.

Currently this command is equivalent to
	git config init.defaultbranch || 'master'

This however will break if at one point the default branch is changed as
indicated by `default_branch_name_advice` in `refs.c`.

I am very sympathetic to the motivation for your patch, I have had to
resort to an ugly hack in Git for Windows' script that generates the
installer: the script creates a throw-away repository _just_ to determine
said branch name.

By providing this command ahead of time users of git can make their
code forward-compatible.

It is probably overkill to introduce a whole new command for just this
single purpose.

But we do have prior art in Git how to display similar information: `git
var -l` will list e.g. `GIT_PAGER`, even if it is not configured
explicitly.

Something like this should be a good start along those lines:

-- snip --

diff --git a/builtin/var.c b/builtin/var.c
index 6c6f46b4aea..937c63939d9 100644
--- a/builtin/var.c
+++ b/builtin/var.c

@@ -5,6 +5,7 @@
  */
 #include "builtin.h"
 #include "config.h"
+#include "refs.h"

 static const char var_usage[] = "git var (-l | <variable>)";

@@ -27,6 +28,16 @@ static const char *pager(int flag)
 	return pgm;
 }

+static const char *default_branch(int flag)
+{
+	const char *name = repo_default_branch_name(the_repository, 1);
+
+	if (!name)
+		BUG("could not determine the default branch name");
+
+	return name;
+}
+
 struct git_var {
 	const char *name;
 	const char *(*read)(int);

@@ -36,6 +47,7 @@ static struct git_var git_vars[] = {
 	{ "GIT_AUTHOR_IDENT",   git_author_info },
 	{ "GIT_EDITOR", editor },
 	{ "GIT_PAGER", pager },
+	{ "GIT_DEFAULT_BRANCH", default_branch },
 	{ "", NULL },
 };

-- snap --

Thanks,
Johannes

Introduce the builtin variable GIT_DEFAULT_BRANCH which represents the
the default branch name that will be used by git-init.

Currently this variable is equivalent to
    git config init.defaultbranch || 'master'

This however will break if at one point the default branch is changed as
indicated by `default_branch_name_advice` in `refs.c`.

By providing this command ahead of time users of git can make their
code forward-compatible.

Co-developed-by: Johannes Schindelin <redacted>
Signed-off-by: Thomas Weißschuh <redacted>
---

Changes from v1 ( https://lore.kernel.org/git/20211030140112.834650-1-thomas@t-8ch.de/ ):
* Replaced the custom subcommand with an internal variable
* Cleaned up the tests

@Johannes: I replaced BUG() with die() from your example because that seems to be
nicer for user facing messages.

 Documentation/git-var.txt |  3 +++
 builtin/var.c             | 13 +++++++++++++
 t/t0007-git-var.sh        | 19 +++++++++++++++++++
 3 files changed, 35 insertions(+)

diff --git a/Documentation/git-var.txt b/Documentation/git-var.txt
index 6072f936ab..387cc1b914 100644
--- a/Documentation/git-var.txt
+++ b/Documentation/git-var.txt

@@ -59,6 +59,9 @@ ifdef::git-default-pager[]
     The build you are using chose '{git-default-pager}' as the default.
 endif::git-default-pager[]
 
+GIT_DEFAULT_BRANCH::
+    The name of the first branch created in newly initialized repositories.
+
 SEE ALSO
 --------
 linkgit:git-commit-tree[1]

diff --git a/builtin/var.c b/builtin/var.c
index 6c6f46b4ae..d1d82b6c93 100644
--- a/builtin/var.c
+++ b/builtin/var.c

@@ -5,6 +5,7 @@
  */
 #include "builtin.h"
 #include "config.h"
+#include "refs.h"
 
 static const char var_usage[] = "git var (-l | <variable>)";
 

@@ -27,6 +28,17 @@ static const char *pager(int flag)
 	return pgm;
 }
 
+static const char *default_branch(int flag)
+{
+	const char *name = repo_default_branch_name(the_repository, 1);
+
+	if (!name)
+		die("could not determine the default branch name");
+
+	return name;
+}
+
+
 struct git_var {
 	const char *name;
 	const char *(*read)(int);

@@ -36,6 +48,7 @@ static struct git_var git_vars[] = {
 	{ "GIT_AUTHOR_IDENT",   git_author_info },
 	{ "GIT_EDITOR", editor },
 	{ "GIT_PAGER", pager },
+	{ "GIT_DEFAULT_BRANCH", default_branch },
 	{ "", NULL },
 };
 

diff --git a/t/t0007-git-var.sh b/t/t0007-git-var.sh
index 53af92d571..6b6852e35e 100755
--- a/t/t0007-git-var.sh
+++ b/t/t0007-git-var.sh

@@ -27,6 +27,25 @@ test_expect_success !FAIL_PREREQS,!AUTOIDENT 'requested identities are strict' '
 	)
 '
 
+test_expect_success 'get GIT_DEFAULT_BRANCH without configuration' '
+	(
+		sane_unset GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME &&
+		echo master >expect &&
+		git var GIT_DEFAULT_BRANCH >actual &&
+		test_cmp expect actual
+	)
+'
+
+test_expect_success 'get GIT_DEFAULT_BRANCH with configuration' '
+	test_config init.defaultbranch foo &&
+	(
+		sane_unset GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME &&
+		echo foo >expect &&
+		git var GIT_DEFAULT_BRANCH >actual &&
+		test_cmp expect actual
+	)
+'
+
 # For git var -l, we check only a representative variable;
 # testing the whole output would make our test too brittle with
 # respect to unrelated changes in the test suite's environment.

base-commit: 0cddd84c9f3e9c3d793ec93034ef679335f35e49
-- 
2.33.1

On Tue, Nov 02 2021, Thomas Weißschuh wrote:

Isn't this die() unrechable given the similar logic in
repo_default_branch_name()? Hence the previous BUG(...)?

I really don't see how it makes sense to add this to "git var", we have
that to correspond to environment variables we use.

*Maybe* if we renamed GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME to
GIT_INITIAL_BRANCH_NAME and made it a non-test thing like
GIT_TEMPLATE_DIR, but even then shouldn't we be adding
"GIT_TEMPLATE_DIR" and any number of other things to this as well?

I'm not saying that your patch needs to do that, but we really should
think about the interface & future implications if we're going in this
direction.

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?

In any case whatever we do here this really should be updating the
documentation of init.defaultbranch & the relevant bits in the "git
init" manpage to add cross-references, similar to how we discuss
GIT_TEMPLATE_DIR now.

1. https://lore.kernel.org/git/211030.86ilxe4edm.gmgdl@evledraar.gmail.com/

On 2021-11-02 17:53+0100, Ævar Arnfjörð Bjarmason wrote:

On Tue, Nov 02 2021, Thomas Weißschuh wrote:

quoted

Introduce the builtin variable GIT_DEFAULT_BRANCH which represents the
the default branch name that will be used by git-init.

Currently this variable is equivalent to
    git config init.defaultbranch || 'master'

This however will break if at one point the default branch is changed as
indicated by `default_branch_name_advice` in `refs.c`.

By providing this command ahead of time users of git can make their
code forward-compatible.

Co-developed-by: Johannes Schindelin <redacted>
Signed-off-by: Thomas Weißschuh <redacted>
---

Changes from v1 ( https://lore.kernel.org/git/20211030140112.834650-1-thomas@t-8ch.de/ ):
* Replaced the custom subcommand with an internal variable
* Cleaned up the tests

@Johannes: I replaced BUG() with die() from your example because that seems to be
nicer for user facing messages.

 Documentation/git-var.txt |  3 +++
 builtin/var.c             | 13 +++++++++++++
 t/t0007-git-var.sh        | 19 +++++++++++++++++++
 3 files changed, 35 insertions(+)

 
+static const char *default_branch(int flag)
+{
+	const char *name = repo_default_branch_name(the_repository, 1);
+
+	if (!name)
+		die("could not determine the default branch name");

Isn't this die() unrechable given the similar logic in
repo_default_branch_name()? Hence the previous BUG(...)?

Ok. Good point.

I really don't see how it makes sense to add this to "git var", we have
that to correspond to environment variables we use.

*Maybe* if we renamed GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME to
GIT_INITIAL_BRANCH_NAME and made it a non-test thing like
GIT_TEMPLATE_DIR, but even then shouldn't we be adding
"GIT_TEMPLATE_DIR" and any number of other things to this as well?

I'm not saying that your patch needs to do that, but we really should
think about the interface & future implications if we're going in this
direction.

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?

In any case whatever we do here this really should be updating the
documentation of init.defaultbranch & the relevant bits in the "git
init" manpage to add cross-references, similar to how we discuss
GIT_TEMPLATE_DIR now.

1. https://lore.kernel.org/git/211030.86ilxe4edm.gmgdl@evledraar.gmail.com/

I'll then wait for a consensus of the git devs. The actual implementation
shouldn't be the issue afterwards.

Thanks for looking into this!

Thomas

On Tue, Nov 02 2021, Thomas Weißschuh wrote:

On 2021-11-02 17:53+0100, Ævar Arnfjörð Bjarmason wrote:

quoted

On Tue, Nov 02 2021, Thomas Weißschuh wrote:

quoted

Introduce the builtin variable GIT_DEFAULT_BRANCH which represents the
the default branch name that will be used by git-init.

Currently this variable is equivalent to
    git config init.defaultbranch || 'master'

This however will break if at one point the default branch is changed as
indicated by `default_branch_name_advice` in `refs.c`.

By providing this command ahead of time users of git can make their
code forward-compatible.

Co-developed-by: Johannes Schindelin <redacted>
Signed-off-by: Thomas Weißschuh <redacted>
---

Changes from v1 ( https://lore.kernel.org/git/20211030140112.834650-1-thomas@t-8ch.de/ ):
* Replaced the custom subcommand with an internal variable
* Cleaned up the tests

@Johannes: I replaced BUG() with die() from your example because that seems to be
nicer for user facing messages.

 Documentation/git-var.txt |  3 +++
 builtin/var.c             | 13 +++++++++++++
 t/t0007-git-var.sh        | 19 +++++++++++++++++++
 3 files changed, 35 insertions(+)

 
+static const char *default_branch(int flag)
+{
+	const char *name = repo_default_branch_name(the_repository, 1);
+
+	if (!name)
+		die("could not determine the default branch name");

Isn't this die() unrechable given the similar logic in
repo_default_branch_name()? Hence the previous BUG(...)?

Ok. Good point.

quoted

I really don't see how it makes sense to add this to "git var", we have
that to correspond to environment variables we use.

*Maybe* if we renamed GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME to
GIT_INITIAL_BRANCH_NAME and made it a non-test thing like
GIT_TEMPLATE_DIR, but even then shouldn't we be adding
"GIT_TEMPLATE_DIR" and any number of other things to this as well?

I'm not saying that your patch needs to do that, but we really should
think about the interface & future implications if we're going in this
direction.

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?

In any case whatever we do here this really should be updating the
documentation of init.defaultbranch & the relevant bits in the "git
init" manpage to add cross-references, similar to how we discuss
GIT_TEMPLATE_DIR now.

1. https://lore.kernel.org/git/211030.86ilxe4edm.gmgdl@evledraar.gmail.com/

I'll then wait for a consensus of the git devs. The actual implementation
shouldn't be the issue afterwards.

Thanks for looking into this!

Please don't take that message as me or anyone else "pulling rank" just
because we've got some previous commits in git.git. That applies to both
me and Johannes, and clearly we disagree on this minor bit of UX
direction.

I'd think if anything the opinion of someone who's not overly familiar
with the system would be more valuable, i.e. yours, especially since you
tried & failed to find a way to do this recently. Would you find it more
intuitive to look in say "git var" over "git config" for this sort of
information?

A further weirdness is that another effective source of config for this
is the "unborn" ls-refs feature[1]. I'm not sure what that means for any
query interface, i.e. would a user want to know what branch a freshly
cloned repo would end up with in advance, taking into account all of the
local config, remote "unborn" etc?

1. https://lore.kernel.org/git/878s8apthr.fsf@evledraar.gmail.com/

On 2021-11-02 20:14+0100, Ævar Arnfjörð Bjarmason wrote:

On Tue, Nov 02 2021, Thomas Weißschuh wrote:

quoted

On 2021-11-02 17:53+0100, Ævar Arnfjörð Bjarmason wrote:

quoted

On Tue, Nov 02 2021, Thomas Weißschuh wrote:

quoted

Introduce the builtin variable GIT_DEFAULT_BRANCH which represents the
the default branch name that will be used by git-init.

Currently this variable is equivalent to
    git config init.defaultbranch || 'master'

This however will break if at one point the default branch is changed as
indicated by `default_branch_name_advice` in `refs.c`.

By providing this command ahead of time users of git can make their
code forward-compatible.

Co-developed-by: Johannes Schindelin <redacted>
Signed-off-by: Thomas Weißschuh <redacted>
---

Changes from v1 ( https://lore.kernel.org/git/20211030140112.834650-1-thomas@t-8ch.de/ ):
* Replaced the custom subcommand with an internal variable
* Cleaned up the tests

@Johannes: I replaced BUG() with die() from your example because that seems to be
nicer for user facing messages.

 Documentation/git-var.txt |  3 +++
 builtin/var.c             | 13 +++++++++++++
 t/t0007-git-var.sh        | 19 +++++++++++++++++++
 3 files changed, 35 insertions(+)

 
+static const char *default_branch(int flag)
+{
+	const char *name = repo_default_branch_name(the_repository, 1);
+
+	if (!name)
+		die("could not determine the default branch name");

Isn't this die() unrechable given the similar logic in
repo_default_branch_name()? Hence the previous BUG(...)?

Ok. Good point.

quoted

I really don't see how it makes sense to add this to "git var", we have
that to correspond to environment variables we use.

*Maybe* if we renamed GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME to
GIT_INITIAL_BRANCH_NAME and made it a non-test thing like
GIT_TEMPLATE_DIR, but even then shouldn't we be adding
"GIT_TEMPLATE_DIR" and any number of other things to this as well?

I'm not saying that your patch needs to do that, but we really should
think about the interface & future implications if we're going in this
direction.

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?

In any case whatever we do here this really should be updating the
documentation of init.defaultbranch & the relevant bits in the "git
init" manpage to add cross-references, similar to how we discuss
GIT_TEMPLATE_DIR now.

1. https://lore.kernel.org/git/211030.86ilxe4edm.gmgdl@evledraar.gmail.com/

I'll then wait for a consensus of the git devs. The actual implementation
shouldn't be the issue afterwards.

Thanks for looking into this!

Please don't take that message as me or anyone else "pulling rank" just
because we've got some previous commits in git.git. That applies to both
me and Johannes, and clearly we disagree on this minor bit of UX
direction.

This was not my impression, although my message has a bit of a resignated
tone. That was not the intention.

I'd think if anything the opinion of someone who's not overly familiar
with the system would be more valuable, i.e. yours, especially since you
tried & failed to find a way to do this recently. Would you find it more
intuitive to look in say "git var" over "git config" for this sort of
information?

To be honest I was not aware of "git var" before Johannes before proposed it.
And I am still not sure how to understand the "logical" aspect of "git-var".
(git-var - Show a Git logical variable)

A "git config" variable using a generic config default framework looks like the
generally cleanest interface.
The appeal of "git var" was the easy and quick implementation.

A further weirdness is that another effective source of config for this
is the "unborn" ls-refs feature[1]. I'm not sure what that means for any
query interface, i.e. would a user want to know what branch a freshly
cloned repo would end up with in advance, taking into account all of the
local config, remote "unborn" etc?

I have no idea how that should work.

1. https://lore.kernel.org/git/878s8apthr.fsf@evledraar.gmail.com/

If you and Johannes think it would help the design-process I would also
volunteer to implement your original proposal:

    git config --get-or-git-default init.defaultBranch

Please note that I'm not doing (primarily) doing this to get commits into
git.git, so if somebody with more knowledge about the git architecture wants to
bring this forward, please feel free.

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

On Wed, Nov 3, 2021 at 7:37 AM Jeff King [off-list ref] wrote:

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.

I almost don't want to mention it since it's not very discoverable
(and is never the first place I think to look), but git-rev-parse
already contains a grab-bag of options unrelated to revision parsing.
Many of the options relate to querying paths (--show-toplevel,
--show-cdup, etc.) or other information related to a repository
(--local-env-vars, --show-object-format, etc.). So, adding
--show-default-branch may be one possibility.