Re: [PATCH] doc: clarify "explicitly given" in push.default

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 28, 2020, 22:11 UTC
Message-ID: <xmqqr1zj6xl6.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <1113893dd36a1e8cf72331dd01f36206b44f45ad.1580116685.git.bert.wesarg@googlemail.com>

Bert Wesarg <bert.wesarg@googlemail.com> writes:

Show 31 quoted lines

> The documentation for push.default mentions that it is used if no
> refspec is "explicitly given". Let's clarify that giving a refspec on
> the command-line _or_ in the config will override it.
>
> Signed-off-by: Jeff King <peff@peff.net>
> Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
> ---
>  Documentation/config/push.txt | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
>
> Cc: peff@peff.net
>
> diff --git a/Documentation/config/push.txt b/Documentation/config/push.txt
> index 0a0e000569..d560362c9a 100644
> --- a/Documentation/config/push.txt
> +++ b/Documentation/config/push.txt
> @@ -1,9 +1,11 @@
>  push.default::
>  	Defines the action `git push` should take if no refspec is
> -	explicitly given.  Different values are well-suited for
> -	specific workflows; for instance, in a purely central workflow
> -	(i.e. the fetch source is equal to the push destination),
> -	`upstream` is probably what you want.  Possible values are:
> +	neither explicitly (on the command-line) nor implicitly (via a
> +	`remote.*.push` config option) given.  Different values are
> +	well-suited for specific workflows; for instance, in a purely
> +	central workflow (i.e. the fetch source is equal to the push
> +	destination), `upstream` is probably what you want.  Possible
> +	values are:
>  +
>  --

Hmph, I am not sure the act of deliberately setting remote.*.push configuration should not count as an explicit request to Git the user makes.

Immediately follows the above, the description of one of the possible values read thusly:

    * `nothing` - do not push anything (error out) unless a refspec is
      explicitly given. This is primarily meant for people who want to
      avoid mistakes by always being explicit.

which may need an adjustment to keep the whole coherent. If we decide to say that setting configuration does not count as explicit, then "unless a refspec is explicitly given" should be updated to match. There may be other mention of "explicitly" that needs to be adjusted (I didn't hunt for it, but the above one was adjacent and I couldn't not see it).

If we have to change anything in the description, I would say that we can just drop "explicitly". There are ways to give refspec from the command line, remote.*.push configuration, in .git/remotes file, etc. If it were "if you give refspec from command line, X happens, but giving a config-sourced refspec does not cause X to happen", that may be a good reason to invent and use a new phrase "implicitly given" that is not used in this paragraph. But push.default kicks in only when *none* of these ways is used to give *any* refspec, so there is not much point differenciating between the command line sourced refspec and config sourced refspec in the context of discussing this feature, I would think.