All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Thomas Weißschuh" <thomas@t-8ch.de>
Cc: git@vger.kernel.org,
	"Johannes Schindelin" <Johannes.Schindelin@gmx.de>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Subject: Re: [PATCH v2] var: add GIT_DEFAULT_BRANCH variable
Date: Wed, 03 Nov 2021 11:21:17 -0700	[thread overview]
Message-ID: <xmqqa6il6qxu.fsf@gitster.g> (raw)
In-Reply-To: <20211102164434.1005707-1-thomas@t-8ch.de> ("Thomas =?utf-8?Q?Wei=C3=9Fschuh=22's?= message of "Tue, 2 Nov 2021 17:44:34 +0100")

Thomas Weißschuh <thomas@t-8ch.de> writes:

> Introduce the builtin variable GIT_DEFAULT_BRANCH which represents the

"builtin" -> "logical", as that is how "git-var" describes these things.

It is totally outside the scope of this patch, but I think we'd
better think of a way to make it clear to the readers of the
documentation that it would not do anything if they did something
like:

    $ GIT_DEFAULT_BRANCH=foobar git init

I say this is outside the scope because there are other existing
logical variables that are different from the environment variables
that can affect the behaviour of git.

> the default branch name that will be used by git-init.

"git-init" -> "git init", or inside a pair of backquotes, i.e. "`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.

Makes sense.  Thanks for cleanly explaining the motivation.

> Co-developed-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>

I would use "Helped-by:" here, as I do not want to see one-off
trailers invented left and right.

> 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);

Calling

        git_default_branch_name(1)

is much shorter and clear.  It's not like using the_repository is
always better.  For a single and simple purpose command like "git
var" that does not run around multiple repositories and do things
in them, sticking to the "we work in _the_ repository given to us"
simple API is better.

> +	if (!name)
> +		die("could not determine the default branch name");
> +
> +	return name;

Should we even die?  What does "init" and "clone" do when they ask
for the same information and get a NULL pointer?

    ... goes and looks ...

They know the call cannot fail that way.  So I would do either

 (1) follow suit and just return whatever we get back from the API
     call to the caller (which knows how to handle a NULL return); or

 (2) call BUG("...")  instead of die().  The name being NULL at this
     point means that git_default_branch_name() returned NULL, which
     the callers do not allow to happen, so it is a BUG for it to
     return NULL, and this caller noticed it.

I only raise the latter as a possibility.  I think just assuming
that name is never NULL like other callers is fine.

Thanks.

  parent reply	other threads:[~2021-11-03 18:21 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
2021-11-03 16:48         ` Eric Sunshine
2021-11-03 18:21     ` Junio C Hamano [this message]
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=xmqqa6il6qxu.fsf@gitster.g \
    --to=gitster@pobox.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.