[Q] push refspec with wildcard pushes all matching branches

[Q] push refspec with wildcard pushes all matching branches

[Bert Wesarg]

Dear all,

I'm a little confused, that a push refspec with a wildcard changes the number of branches pushed.

Here is what I see with Git 2.25:

     $ git --version
     git version 2.25.0
     $ git config --list
     user.email=bert.wesarg@googlemail.com
     user.name=Bert Wesarg
     $ git init --bare bare.git
     $ git clone bare.git repo
     Cloning into 'repo'...
     warning: You appear to have cloned an empty repository.
     done.
     $ cd repo
     $ git config push.default current
     $ echo foo >foo
     $ git add foo
     $ git commit -m foo
     [master (root-commit) 4d0b276] foo
      1 file changed, 1 insertion(+)
      create mode 100644 foo
     $ git branch master-two
     $ git push --dry-run
     To ../bare.git
      * [new branch]      master -> master
     $ git config remote.origin.push 'refs/heads/master*:refs/remotes/origin/master*'
     $ git push --dry-run
     To ../bare.git
      * [new branch]      master -> origin/master
      * [new branch]      master-two -> origin/master-two

Is this expected behavior?

Thanks.

Best,
Bert

Re: [Q] push refspec with wildcard pushes all matching branches

[Jeff King]

On Fri, Jan 24, 2020 at 09:29:53PM +0100, Bert Wesarg wrote:

> I'm a little confused, that a push refspec with a wildcard changes the number of branches pushed.

I'm confused about which part you're confused about. :)

>     $ git push --dry-run
>     To ../bare.git
>      * [new branch]      master -> master
>     $ git config remote.origin.push 'refs/heads/master*:refs/remotes/origin/master*'
>     $ git push --dry-run
>     To ../bare.git
>      * [new branch]      master -> origin/master
>      * [new branch]      master-two -> origin/master-two
> 
> Is this expected behavior?

You asked it to push master*, so it did.

Is your confusion that you had set push.default to "current"? If there
is a refspec (either in the config or specified on the command line),
then that takes precedence over push.default.

From git-push(1):

  When the command line does not specify what to push with <refspec>...
  arguments or --all, --mirror, --tags options, the command finds the
  default <refspec> by consulting remote.*.push configuration, and if it
  is not found, honors push.default configuration to decide what to push
  (See git-config(1) for the meaning of push.default).

If that's not it, can you clarify what you expected to happen?

-Peff

Re: [Q] push refspec with wildcard pushes all matching branches

[Bert Wesarg]

On 25.01.20 01:38, Jeff King wrote:
> On Fri, Jan 24, 2020 at 09:29:53PM +0100, Bert Wesarg wrote:
> 
>> I'm a little confused, that a push refspec with a wildcard changes the number of branches pushed.
> 
> I'm confused about which part you're confused about. :)
> 
>>      $ git push --dry-run
>>      To ../bare.git
>>       * [new branch]      master -> master
>>      $ git config remote.origin.push 'refs/heads/master*:refs/remotes/origin/master*'
>>      $ git push --dry-run
>>      To ../bare.git
>>       * [new branch]      master -> origin/master
>>       * [new branch]      master-two -> origin/master-two
>>
>> Is this expected behavior?
> 
> You asked it to push master*, so it did.
> 
> Is your confusion that you had set push.default to "current"? If there
> is a refspec (either in the config or specified on the command line),
> then that takes precedence over push.default.
> 
>  From git-push(1):
> 
>    When the command line does not specify what to push with <refspec>...
>    arguments or --all, --mirror, --tags options, the command finds the
>    default <refspec> by consulting remote.*.push configuration, and if it
>    is not found, honors push.default configuration to decide what to push
>    (See git-config(1) for the meaning of push.default).
> 
> If that's not it, can you clarify what you expected to happen?

thanks for this pointer. My initial pointer was the help for push.default:

  From git-config(1):

        push.default
            Defines the action git push should take if no refspec is explicitly
            given. Different values are well-suited for specific workflows; for

Thus I expected, that this takes effect, when just calling 'git push'.

What I actually want to achieve, is to track a remote branch with a different name locally, but 'git push' should nevertheless push to tracked remote branch.

In my example above, befor adding the 'push.origin.push' refspec, rename the branch:

     $ git branch -m local
     $ git push --dry-run
       To ../bare.git
        * [new branch]      local -> local

Is it possible that this pushes to the tracked branch automatically, and because I have multiple such branches, without the use of a push refspec.

Thanks for the help.

Best,
Bert

> 
> -Peff
> 

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

[Jeff King]

On Sat, Jan 25, 2020 at 08:38:04AM +0100, Bert Wesarg wrote:

> thanks for this pointer. My initial pointer was the help for push.default:
> 
>  From git-config(1):
> 
>        push.default
>            Defines the action git push should take if no refspec is explicitly
>            given. Different values are well-suited for specific workflows; for
> 
> Thus I expected, that this takes effect, when just calling 'git push'.

Yeah, I agree "explicitly given" is vague there. Perhaps the patch below
is worth doing?

> What I actually want to achieve, is to track a remote branch with a
> different name locally, but 'git push' should nevertheless push to
> tracked remote branch.
> 
> In my example above, befor adding the 'push.origin.push' refspec, rename the branch:
> 
>     $ git branch -m local
>     $ git push --dry-run
>       To ../bare.git
>        * [new branch]      local -> local
> 
> Is it possible that this pushes to the tracked branch automatically,
> and because I have multiple such branches, without the use of a push
> refspec.

I think if push.default is set to "upstream" then it would do what you
want as long as you set the upstream of "local" (e.g., by doing "git
branch --set-upstream-to=origin/master local).

There's another way of doing this, which is when you have a "triangular"
flow: you might pull changes from origin/master into your local branch
X, but then push them elsewhere. Usually this would be pushing to a
branch named X on a different remote than origin (e.g., your public fork
of upstream on a server). And for that you can set branch.X.pushRemote.

There's no corresponding triangular config branch.X.pushBranch to push
to a different name than "X" on the remote. And while I do think it
would be rare to want it, I could imagine a case (you have a triangular
flow where everybody shares a central repo, but you want to push to some
local namespace within it; usually people do that now by just making the
namespace part of their local branch names, too).

Anyway, here's the documentation patch.

-- >8 --
Subject: [PATCH] doc: clarify "explicitly given" in push.default

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>
---
 Documentation/config/push.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/config/push.txt b/Documentation/config/push.txt
index 0a0e000569..554ab44b4c 100644
--- a/Documentation/config/push.txt
+++ b/Documentation/config/push.txt
@@ -1,6 +1,7 @@
 push.default::
 	Defines the action `git push` should take if no refspec is
-	explicitly given.  Different values are well-suited for
+	explicitly given (either on the command-line or via a
+	`remote.*.push` config option). 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:
-- 
2.25.0.430.g8dfc7de6f7

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

[Bert Wesarg]

On 25.01.20 21:05, Jeff King wrote:
> On Sat, Jan 25, 2020 at 08:38:04AM +0100, Bert Wesarg wrote:
> 
>> thanks for this pointer. My initial pointer was the help for push.default:
>>
>>   From git-config(1):
>>
>>         push.default
>>             Defines the action git push should take if no refspec is explicitly
>>             given. Different values are well-suited for specific workflows; for
>>
>> Thus I expected, that this takes effect, when just calling 'git push'.
> 
> Yeah, I agree "explicitly given" is vague there. Perhaps the patch below
> is worth doing?
> 
>> What I actually want to achieve, is to track a remote branch with a
>> different name locally, but 'git push' should nevertheless push to
>> tracked remote branch.
>>
>> In my example above, befor adding the 'push.origin.push' refspec, rename the branch:
>>
>>      $ git branch -m local
>>      $ git push --dry-run
>>        To ../bare.git
>>         * [new branch]      local -> local
>>
>> Is it possible that this pushes to the tracked branch automatically,
>> and because I have multiple such branches, without the use of a push
>> refspec.
> 
> I think if push.default is set to "upstream" then it would do what you
> want as long as you set the upstream of "local" (e.g., by doing "git
> branch --set-upstream-to=origin/master local).

Thanks. This pushes only the current branch and honors the 'rename'.

> 
> There's another way of doing this, which is when you have a "triangular"
> flow: you might pull changes from origin/master into your local branch
> X, but then push them elsewhere. Usually this would be pushing to a
> branch named X on a different remote than origin (e.g., your public fork
> of upstream on a server). And for that you can set branch.X.pushRemote.
> 
> There's no corresponding triangular config branch.X.pushBranch to push
> to a different name than "X" on the remote. And while I do think it
> would be rare to want it, I could imagine a case (you have a triangular
> flow where everybody shares a central repo, but you want to push to some
> local namespace within it; usually people do that now by just making the
> namespace part of their local branch names, too).
> 
> Anyway, here's the documentation patch.
> 
> -- >8 --
> Subject: [PATCH] doc: clarify "explicitly given" in push.default
> 
> 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>
> ---
>   Documentation/config/push.txt | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/config/push.txt b/Documentation/config/push.txt
> index 0a0e000569..554ab44b4c 100644
> --- a/Documentation/config/push.txt
> +++ b/Documentation/config/push.txt
> @@ -1,6 +1,7 @@
>   push.default::
>   	Defines the action `git push` should take if no refspec is
> -	explicitly given.  Different values are well-suited for
> +	explicitly given (either on the command-line or via a
> +	`remote.*.push` config option). Different values are well-suited for
>   	specific workflows; for instance, in a purely central workflow
>   	`upstream` is probably what you want.  Possible values are:
> 

I would rather talk about 'implicitly given', if it is via a `remote.*.push` config option:

  	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:


Bert

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

[Jeff King]

On Mon, Jan 27, 2020 at 08:00:22AM +0100, Bert Wesarg wrote:

> > diff --git a/Documentation/config/push.txt b/Documentation/config/push.txt
> > index 0a0e000569..554ab44b4c 100644
> > --- a/Documentation/config/push.txt
> > +++ b/Documentation/config/push.txt
> > @@ -1,6 +1,7 @@
> >   push.default::
> >   	Defines the action `git push` should take if no refspec is
> > -	explicitly given.  Different values are well-suited for
> > +	explicitly given (either on the command-line or via a
> > +	`remote.*.push` config option). Different values are well-suited for
> >   	specific workflows; for instance, in a purely central workflow
> >   	`upstream` is probably what you want.  Possible values are:
> > 
> 
> I would rather talk about 'implicitly given', if it is via a `remote.*.push` config option:
> 
>  	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:

Yeah, that sounds fine. Want to wrap it up with as a patch with a commit
message?

-Peff

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

[Bert Wesarg]

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:
 +
 --
 
-- 
2.24.1.497.g9abd7b20b4.dirty

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

[Bert Wesarg]

Dear Jeff,

On 27.01.20 08:00, Bert Wesarg wrote:
> On 25.01.20 21:05, Jeff King wrote:
>> On Sat, Jan 25, 2020 at 08:38:04AM +0100, Bert Wesarg wrote:
>>
>>> thanks for this pointer. My initial pointer was the help for push.default:
>>>
>>>   From git-config(1):
>>>
>>>         push.default
>>>             Defines the action git push should take if no refspec is explicitly
>>>             given. Different values are well-suited for specific workflows; for
>>>
>>> Thus I expected, that this takes effect, when just calling 'git push'.
>>
>> Yeah, I agree "explicitly given" is vague there. Perhaps the patch below
>> is worth doing?
>>
>>> What I actually want to achieve, is to track a remote branch with a
>>> different name locally, but 'git push' should nevertheless push to
>>> tracked remote branch.
>>>
>>> In my example above, befor adding the 'push.origin.push' refspec, rename the branch:
>>>
>>>      $ git branch -m local
>>>      $ git push --dry-run
>>>        To ../bare.git
>>>         * [new branch]      local -> local
>>>
>>> Is it possible that this pushes to the tracked branch automatically,
>>> and because I have multiple such branches, without the use of a push
>>> refspec.
>>
>> I think if push.default is set to "upstream" then it would do what you
>> want as long as you set the upstream of "local" (e.g., by doing "git
>> branch --set-upstream-to=origin/master local).
> 
> Thanks. This pushes only the current branch and honors the 'rename'.

while this works …

> 
>>
>> There's another way of doing this, which is when you have a "triangular"
>> flow: you might pull changes from origin/master into your local branch
>> X, but then push them elsewhere. Usually this would be pushing to a
>> branch named X on a different remote than origin (e.g., your public fork
>> of upstream on a server). And for that you can set branch.X.pushRemote.

… it does not play well if you have have both flows in one repository. And I do have both flows. I track the upstream 'master' in the local branch 'Y' and I have also a branch 'X' which is based on 'Y' but should be pushed to a different remote as branch 'Y'. I have configured 'branch.X.pushRemote = triangular' but with 'push.default' set to 'upstream' I get this when:

     $ git push triangular
     fatal: You are pushing to remote 'triangular', which is not the upstream of
     your current branch 'X', without telling me what to push
     to update which remote branch.

In this simple case, without a renaming, I would expect that 'git push' just works. May be just fallback to 'simple' if 'upstream' does not resolve to a fully qualified push?

Best,
Bert

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

[Bert Wesarg]

On 27.01.20 20:48, Bert Wesarg wrote:
> Dear Jeff,
> 
> On 27.01.20 08:00, Bert Wesarg wrote:
>> On 25.01.20 21:05, Jeff King wrote:
>>> On Sat, Jan 25, 2020 at 08:38:04AM +0100, Bert Wesarg wrote:
>>>
>>>> thanks for this pointer. My initial pointer was the help for push.default:
>>>>
>>>>   From git-config(1):
>>>>
>>>>         push.default
>>>>             Defines the action git push should take if no refspec is explicitly
>>>>             given. Different values are well-suited for specific workflows; for
>>>>
>>>> Thus I expected, that this takes effect, when just calling 'git push'.
>>>
>>> Yeah, I agree "explicitly given" is vague there. Perhaps the patch below
>>> is worth doing?
>>>
>>>> What I actually want to achieve, is to track a remote branch with a
>>>> different name locally, but 'git push' should nevertheless push to
>>>> tracked remote branch.
>>>>
>>>> In my example above, befor adding the 'push.origin.push' refspec, rename the branch:
>>>>
>>>>      $ git branch -m local
>>>>      $ git push --dry-run
>>>>        To ../bare.git
>>>>         * [new branch]      local -> local
>>>>
>>>> Is it possible that this pushes to the tracked branch automatically,
>>>> and because I have multiple such branches, without the use of a push
>>>> refspec.
>>>
>>> I think if push.default is set to "upstream" then it would do what you
>>> want as long as you set the upstream of "local" (e.g., by doing "git
>>> branch --set-upstream-to=origin/master local).
>>
>> Thanks. This pushes only the current branch and honors the 'rename'.
> 
> while this works …
> 
>>
>>>
>>> There's another way of doing this, which is when you have a "triangular"
>>> flow: you might pull changes from origin/master into your local branch
>>> X, but then push them elsewhere. Usually this would be pushing to a
>>> branch named X on a different remote than origin (e.g., your public fork
>>> of upstream on a server). And for that you can set branch.X.pushRemote.
> 
> … it does not play well if you have have both flows in one repository. And I do have both flows. I track the upstream 'master' in the local branch 'Y' and I have also a branch 'X' which is based on 'Y' but should be pushed to a different remote as branch 'Y'. I have configured 'branch.X.pushRemote = triangular' but with 'push.default' set to 'upstream' I get this when:
> 
>      $ git push triangular
>      fatal: You are pushing to remote 'triangular', which is not the upstream of
>      your current branch 'X', without telling me what to push
>      to update which remote branch.
> 
> In this simple case, without a renaming, I would expect that 'git push' just works. May be just fallback to 'simple' if 'upstream' does not resolve to a fully qualified push?

Falling back to simple/current seems to work for my case:

diff --git a/builtin/push.c b/builtin/push.c
index 6dbf0f0bb7..6b2fac7977 100644 builtin/push.c
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -259,7 +259,10 @@ static void setup_default_push_refspecs(struct remote *remote)
                 break;
  
         case PUSH_DEFAULT_UPSTREAM:
-               setup_push_upstream(remote, branch, triangular, 0);
+               if (triangular)
+                       setup_push_current(remote, branch);
+               else
+                       setup_push_upstream(remote, branch, triangular, 0);
                 break;
  
         case PUSH_DEFAULT_CURRENT:

It has some fallouts in the test suite, obviously. But is this something we should pursue at all?

Bert

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

[Jeff King]

On Mon, Jan 27, 2020 at 10:25:03AM +0100, Bert Wesarg wrote:

> 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.

Yep, looks good to me.

> Signed-off-by: Jeff King <peff@peff.net>
> Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>

I don't know that we need my S-o-b anymore. The content in this one is
all you. :) (But certainly I don't mind endorsing it).

-Peff

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

[Jeff King]

On Mon, Jan 27, 2020 at 08:48:01PM +0100, Bert Wesarg wrote:

> > > There's another way of doing this, which is when you have a "triangular"
> > > flow: you might pull changes from origin/master into your local branch
> > > X, but then push them elsewhere. Usually this would be pushing to a
> > > branch named X on a different remote than origin (e.g., your public fork
> > > of upstream on a server). And for that you can set branch.X.pushRemote.
> 
> … it does not play well if you have have both flows in one repository.
> And I do have both flows. I track the upstream 'master' in the local
> branch 'Y' and I have also a branch 'X' which is based on 'Y' but
> should be pushed to a different remote as branch 'Y'. I have
> configured 'branch.X.pushRemote = triangular' but with 'push.default'
> set to 'upstream' I get this when:
> 
>     $ git push triangular
>     fatal: You are pushing to remote 'triangular', which is not the upstream of
>     your current branch 'X', without telling me what to push
>     to update which remote branch.
> 
> In this simple case, without a renaming, I would expect that 'git
> push' just works. May be just fallback to 'simple' if 'upstream' does
> not resolve to a fully qualified push?

I thought the point of "simple" was to be even more restrictive than
"upstream".

At any rate, your setup is sufficiently complicated that I think you'd
be better off adding a branch.X.pushRef feature (essentially a refspec
to be used just on branch X, though since the source side is implied,
it's really just a destination ref).

-Peff

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

[Bert Wesarg]

On Tue, Jan 28, 2020 at 12:15 AM Jeff King <peff@peff.net> wrote:
>
> On Mon, Jan 27, 2020 at 08:48:01PM +0100, Bert Wesarg wrote:
>
> > > > There's another way of doing this, which is when you have a "triangular"
> > > > flow: you might pull changes from origin/master into your local branch
> > > > X, but then push them elsewhere. Usually this would be pushing to a
> > > > branch named X on a different remote than origin (e.g., your public fork
> > > > of upstream on a server). And for that you can set branch.X.pushRemote.
> >
> > … it does not play well if you have have both flows in one repository.
> > And I do have both flows. I track the upstream 'master' in the local
> > branch 'Y' and I have also a branch 'X' which is based on 'Y' but
> > should be pushed to a different remote as branch 'Y'. I have
> > configured 'branch.X.pushRemote = triangular' but with 'push.default'
> > set to 'upstream' I get this when:
> >
> >     $ git push triangular
> >     fatal: You are pushing to remote 'triangular', which is not the upstream of
> >     your current branch 'X', without telling me what to push
> >     to update which remote branch.
> >
> > In this simple case, without a renaming, I would expect that 'git
> > push' just works. May be just fallback to 'simple' if 'upstream' does
> > not resolve to a fully qualified push?
>
> I thought the point of "simple" was to be even more restrictive than
> "upstream".
>
> At any rate, your setup is sufficiently complicated that I think you'd
> be better off adding a branch.X.pushRef feature (essentially a refspec
> to be used just on branch X, though since the source side is implied,
> it's really just a destination ref).

thanks. I will try to come up with a patch.

Bert

>
> -Peff

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

[Junio C Hamano]

Bert Wesarg <bert.wesarg@googlemail.com> 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@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.

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

[Jeff King]

On Tue, Jan 28, 2020 at 02:11:01PM -0800, Junio C Hamano wrote:

> >  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. 

Yeah, you're right. The term "explicit" gets thrown around a fair bit
there.

In that sense my original was slightly better, in that it defines
"explicit" (one might say it even does so...explicitly). But...

> If we have to change anything in the description, I would say that
> we can just drop "explicitly". [...]

Yes, I like dropping that word even better.

Though I'd still slightly worry that somebody might not consider
configured refspecs. Saying more clearly "any refspec no matter where it
comes from" might still be worthwhile. I.e., something like:

  Defines the action `git push` should take if no refspec is given
  (whether from the command-line, config, or elsewhere).

?

-Peff

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

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> Though I'd still slightly worry that somebody might not consider
> configured refspecs. Saying more clearly "any refspec no matter where it
> comes from" might still be worthwhile. I.e., something like:
>
>   Defines the action `git push` should take if no refspec is given
>   (whether from the command-line, config, or elsewhere).

That's 100x better than to say "explicit" "implicit" etc. and then
have readers guess what the adjectives mean or explain what they
mean in (parentheses).

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

[Jeff King]

On Tue, Jan 28, 2020 at 09:21:32PM -0800, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > Though I'd still slightly worry that somebody might not consider
> > configured refspecs. Saying more clearly "any refspec no matter where it
> > comes from" might still be worthwhile. I.e., something like:
> >
> >   Defines the action `git push` should take if no refspec is given
> >   (whether from the command-line, config, or elsewhere).
> 
> That's 100x better than to say "explicit" "implicit" etc. and then
> have readers guess what the adjectives mean or explain what they
> mean in (parentheses).

OK, here it is in patch form, then, so we can (hopefully) wrap this up.

-- >8 --
Subject: [PATCH] doc: drop "explicitly given" from push.default description

The documentation for push.default mentions that it is used if no
refspec is "explicitly given". Let's drop the notion of "explicit" here,
since it's vague, and just mention that any refspec from anywhere is
sufficient to override this.

I've dropped the mention of "explicitly given" frmo the definition of
the "nothing" value right below, too. It's close enough to our
clarification that it should be obvious we mean the same type of "given"
here.

Signed-off-by: Jeff King <peff@peff.net>
---
Note that there's one other use of the word "explicit" in the context,
but it is used appropriately. :)

 Documentation/config/push.txt | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/config/push.txt b/Documentation/config/push.txt
index 0a0e000569..54871f8213 100644
--- a/Documentation/config/push.txt
+++ b/Documentation/config/push.txt
@@ -1,14 +1,15 @@
 push.default::
 	Defines the action `git push` should take if no refspec is
-	explicitly given.  Different values are well-suited for
+	given (whether from the command-line, config, or elsewhere).
+	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:
 +
 --
 
 * `nothing` - do not push anything (error out) unless a refspec is
-  explicitly given. This is primarily meant for people who want to
+  given. This is primarily meant for people who want to
   avoid mistakes by always being explicit.
 
 * `current` - push the current branch to update a branch with the same
-- 
2.25.0.515.g69a699b7aa