Bert Wesarg <bert.wesarg@xxxxxxxxxxxxxx> writes:
> 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@xxxxxxxx>
> Signed-off-by: Bert Wesarg <bert.wesarg@xxxxxxxxxxxxxx>
> ---
> Documentation/config/push.txt | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> Cc: peff@xxxxxxxx
>
> 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.
