{"thread":{"id":"52691","subject":"[Q] push refspec with wildcard pushes all matching branches","startedAt":"2020-01-24T20:29:58Z","lastAt":"2020-01-29T05:53:58Z","messageCount":16,"participants":["Bert Wesarg","Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"390389","messageId":"ed9a0485-1e6c-79ae-6a59-655105203728@googlemail.com","threadId":"52691","inReplyTo":null,"subject":"[Q] push refspec with wildcard pushes all matching branches","fromName":"Bert Wesarg","fromEmail":"bert.wesarg@googlemail.com","sentAt":"2020-01-24T20:29:53Z","receivedAt":"2020-01-24T20:29:58Z","isPatch":false,"sender":{"key":"bert.wesarg@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/111934?v=4"},"body":"Dear all,\n\nI'm a little confused, that a push refspec with a wildcard changes the number of branches pushed.\n\nHere is what I see with Git 2.25:\n\n     $ git --version\n     git version 2.25.0\n     $ git config --list\n     user.email=bert.wesarg@googlemail.com\n     user.name=Bert Wesarg\n     $ git init --bare bare.git\n     $ git clone bare.git repo\n     Cloning into 'repo'...\n     warning: You appear to have cloned an empty repository.\n     done.\n     $ cd repo\n     $ git config push.default current\n     $ echo foo >foo\n     $ git add foo\n     $ git commit -m foo\n     [master (root-commit) 4d0b276] foo\n      1 file changed, 1 insertion(+)\n      create mode 100644 foo\n     $ git branch master-two\n     $ git push --dry-run\n     To ../bare.git\n      * [new branch]      master -> master\n     $ git config remote.origin.push 'refs/heads/master*:refs/remotes/origin/master*'\n     $ git push --dry-run\n     To ../bare.git\n      * [new branch]      master -> origin/master\n      * [new branch]      master-two -> origin/master-two\n\nIs this expected behavior?\n\nThanks.\n\nBest,\nBert\n"},{"id":"390434","messageId":"20200125003836.GA568952@coredump.intra.peff.net","threadId":"52691","inReplyTo":"ed9a0485-1e6c-79ae-6a59-655105203728@googlemail.com","subject":"Re: [Q] push refspec with wildcard pushes all matching branches","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-01-25T00:38:36Z","receivedAt":"2020-01-25T00:38:39Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jan 24, 2020 at 09:29:53PM +0100, Bert Wesarg wrote:\n\n> I'm a little confused, that a push refspec with a wildcard changes the number of branches pushed.\n\nI'm confused about which part you're confused about. :)\n\n>     $ git push --dry-run\n>     To ../bare.git\n>      * [new branch]      master -> master\n>     $ git config remote.origin.push 'refs/heads/master*:refs/remotes/origin/master*'\n>     $ git push --dry-run\n>     To ../bare.git\n>      * [new branch]      master -> origin/master\n>      * [new branch]      master-two -> origin/master-two\n> \n> Is this expected behavior?\n\nYou asked it to push master*, so it did.\n\nIs your confusion that you had set push.default to \"current\"? If there\nis a refspec (either in the config or specified on the command line),\nthen that takes precedence over push.default.\n\nFrom git-push(1):\n\n  When the command line does not specify what to push with <refspec>...\n  arguments or --all, --mirror, --tags options, the command finds the\n  default <refspec> by consulting remote.*.push configuration, and if it\n  is not found, honors push.default configuration to decide what to push\n  (See git-config(1) for the meaning of push.default).\n\nIf that's not it, can you clarify what you expected to happen?\n\n-Peff\n"},{"id":"390452","messageId":"b4c31e50-6da5-7699-1069-d94091f768bd@googlemail.com","threadId":"52691","inReplyTo":"20200125003836.GA568952@coredump.intra.peff.net","subject":"Re: [Q] push refspec with wildcard pushes all matching branches","fromName":"Bert Wesarg","fromEmail":"bert.wesarg@googlemail.com","sentAt":"2020-01-25T07:38:04Z","receivedAt":"2020-01-25T07:38:09Z","isPatch":false,"sender":{"key":"bert.wesarg@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/111934?v=4"},"body":"\n\nOn 25.01.20 01:38, Jeff King wrote:\n> On Fri, Jan 24, 2020 at 09:29:53PM +0100, Bert Wesarg wrote:\n> \n>> I'm a little confused, that a push refspec with a wildcard changes the number of branches pushed.\n> \n> I'm confused about which part you're confused about. :)\n> \n>>      $ git push --dry-run\n>>      To ../bare.git\n>>       * [new branch]      master -> master\n>>      $ git config remote.origin.push 'refs/heads/master*:refs/remotes/origin/master*'\n>>      $ git push --dry-run\n>>      To ../bare.git\n>>       * [new branch]      master -> origin/master\n>>       * [new branch]      master-two -> origin/master-two\n>>\n>> Is this expected behavior?\n> \n> You asked it to push master*, so it did.\n> \n> Is your confusion that you had set push.default to \"current\"? If there\n> is a refspec (either in the config or specified on the command line),\n> then that takes precedence over push.default.\n> \n>  From git-push(1):\n> \n>    When the command line does not specify what to push with <refspec>...\n>    arguments or --all, --mirror, --tags options, the command finds the\n>    default <refspec> by consulting remote.*.push configuration, and if it\n>    is not found, honors push.default configuration to decide what to push\n>    (See git-config(1) for the meaning of push.default).\n> \n> If that's not it, can you clarify what you expected to happen?\n\nthanks for this pointer. My initial pointer was the help for push.default:\n\n  From git-config(1):\n\n        push.default\n            Defines the action git push should take if no refspec is explicitly\n            given. Different values are well-suited for specific workflows; for\n\nThus I expected, that this takes effect, when just calling 'git push'.\n\nWhat 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.\n\nIn my example above, befor adding the 'push.origin.push' refspec, rename the branch:\n\n     $ git branch -m local\n     $ git push --dry-run\n       To ../bare.git\n        * [new branch]      local -> local\n\nIs it possible that this pushes to the tracked branch automatically, and because I have multiple such branches, without the use of a push refspec.\n\nThanks for the help.\n\nBest,\nBert\n\n> \n> -Peff\n> \n"},{"id":"390467","messageId":"20200125200554.GC5519@coredump.intra.peff.net","threadId":"52691","inReplyTo":"b4c31e50-6da5-7699-1069-d94091f768bd@googlemail.com","subject":"[PATCH] doc: clarify \"explicitly given\" in push.default","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-01-25T20:05:54Z","receivedAt":"2020-01-25T20:05:58Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Jan 25, 2020 at 08:38:04AM +0100, Bert Wesarg wrote:\n\n> thanks for this pointer. My initial pointer was the help for push.default:\n> \n>  From git-config(1):\n> \n>        push.default\n>            Defines the action git push should take if no refspec is explicitly\n>            given. Different values are well-suited for specific workflows; for\n> \n> Thus I expected, that this takes effect, when just calling 'git push'.\n\nYeah, I agree \"explicitly given\" is vague there. Perhaps the patch below\nis worth doing?\n\n> What I actually want to achieve, is to track a remote branch with a\n> different name locally, but 'git push' should nevertheless push to\n> tracked remote branch.\n> \n> In my example above, befor adding the 'push.origin.push' refspec, rename the branch:\n> \n>     $ git branch -m local\n>     $ git push --dry-run\n>       To ../bare.git\n>        * [new branch]      local -> local\n> \n> Is it possible that this pushes to the tracked branch automatically,\n> and because I have multiple such branches, without the use of a push\n> refspec.\n\nI think if push.default is set to \"upstream\" then it would do what you\nwant as long as you set the upstream of \"local\" (e.g., by doing \"git\nbranch --set-upstream-to=origin/master local).\n\nThere's another way of doing this, which is when you have a \"triangular\"\nflow: you might pull changes from origin/master into your local branch\nX, but then push them elsewhere. Usually this would be pushing to a\nbranch named X on a different remote than origin (e.g., your public fork\nof upstream on a server). And for that you can set branch.X.pushRemote.\n\nThere's no corresponding triangular config branch.X.pushBranch to push\nto a different name than \"X\" on the remote. And while I do think it\nwould be rare to want it, I could imagine a case (you have a triangular\nflow where everybody shares a central repo, but you want to push to some\nlocal namespace within it; usually people do that now by just making the\nnamespace part of their local branch names, too).\n\nAnyway, here's the documentation patch.\n\n-- >8 --\nSubject: [PATCH] doc: clarify \"explicitly given\" in push.default\n\nThe documentation for push.default mentions that it is used if no\nrefspec is \"explicitly given\". Let's clarify that giving a refspec on\nthe command-line _or_ in the config will override it.\n\nSigned-off-by: Jeff King <peff@peff.net>\n---\n Documentation/config/push.txt | 3 ++-\n 1 file changed, 2 insertions(+), 1 deletion(-)\n\ndiff --git a/Documentation/config/push.txt b/Documentation/config/push.txt\nindex 0a0e000569..554ab44b4c 100644\n--- a/Documentation/config/push.txt\n+++ b/Documentation/config/push.txt\n@@ -1,6 +1,7 @@\n push.default::\n \tDefines the action `git push` should take if no refspec is\n-\texplicitly given.  Different values are well-suited for\n+\texplicitly given (either on the command-line or via a\n+\t`remote.*.push` config option). Different values are well-suited for\n \tspecific workflows; for instance, in a purely central workflow\n \t(i.e. the fetch source is equal to the push destination),\n \t`upstream` is probably what you want.  Possible values are:\n-- \n2.25.0.430.g8dfc7de6f7\n\n"},{"id":"390535","messageId":"d8007df9-002b-6db1-4769-d6bf8c338cdf@googlemail.com","threadId":"52691","inReplyTo":"20200125200554.GC5519@coredump.intra.peff.net","subject":"Re: [PATCH] doc: clarify \"explicitly given\" in push.default","fromName":"Bert Wesarg","fromEmail":"bert.wesarg@googlemail.com","sentAt":"2020-01-27T07:00:22Z","receivedAt":"2020-01-27T07:00:28Z","isPatch":true,"sender":{"key":"bert.wesarg@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/111934?v=4"},"body":"On 25.01.20 21:05, Jeff King wrote:\n> On Sat, Jan 25, 2020 at 08:38:04AM +0100, Bert Wesarg wrote:\n> \n>> thanks for this pointer. My initial pointer was the help for push.default:\n>>\n>>   From git-config(1):\n>>\n>>         push.default\n>>             Defines the action git push should take if no refspec is explicitly\n>>             given. Different values are well-suited for specific workflows; for\n>>\n>> Thus I expected, that this takes effect, when just calling 'git push'.\n> \n> Yeah, I agree \"explicitly given\" is vague there. Perhaps the patch below\n> is worth doing?\n> \n>> What I actually want to achieve, is to track a remote branch with a\n>> different name locally, but 'git push' should nevertheless push to\n>> tracked remote branch.\n>>\n>> In my example above, befor adding the 'push.origin.push' refspec, rename the branch:\n>>\n>>      $ git branch -m local\n>>      $ git push --dry-run\n>>        To ../bare.git\n>>         * [new branch]      local -> local\n>>\n>> Is it possible that this pushes to the tracked branch automatically,\n>> and because I have multiple such branches, without the use of a push\n>> refspec.\n> \n> I think if push.default is set to \"upstream\" then it would do what you\n> want as long as you set the upstream of \"local\" (e.g., by doing \"git\n> branch --set-upstream-to=origin/master local).\n\nThanks. This pushes only the current branch and honors the 'rename'.\n\n> \n> There's another way of doing this, which is when you have a \"triangular\"\n> flow: you might pull changes from origin/master into your local branch\n> X, but then push them elsewhere. Usually this would be pushing to a\n> branch named X on a different remote than origin (e.g., your public fork\n> of upstream on a server). And for that you can set branch.X.pushRemote.\n> \n> There's no corresponding triangular config branch.X.pushBranch to push\n> to a different name than \"X\" on the remote. And while I do think it\n> would be rare to want it, I could imagine a case (you have a triangular\n> flow where everybody shares a central repo, but you want to push to some\n> local namespace within it; usually people do that now by just making the\n> namespace part of their local branch names, too).\n> \n> Anyway, here's the documentation patch.\n> \n> -- >8 --\n> Subject: [PATCH] doc: clarify \"explicitly given\" in push.default\n> \n> The documentation for push.default mentions that it is used if no\n> refspec is \"explicitly given\". Let's clarify that giving a refspec on\n> the command-line _or_ in the config will override it.\n> \n> Signed-off-by: Jeff King <peff@peff.net>\n> ---\n>   Documentation/config/push.txt | 3 ++-\n>   1 file changed, 2 insertions(+), 1 deletion(-)\n> \n> diff --git a/Documentation/config/push.txt b/Documentation/config/push.txt\n> index 0a0e000569..554ab44b4c 100644\n> --- a/Documentation/config/push.txt\n> +++ b/Documentation/config/push.txt\n> @@ -1,6 +1,7 @@\n>   push.default::\n>   \tDefines the action `git push` should take if no refspec is\n> -\texplicitly given.  Different values are well-suited for\n> +\texplicitly given (either on the command-line or via a\n> +\t`remote.*.push` config option). Different values are well-suited for\n>   \tspecific workflows; for instance, in a purely central workflow\n>   \t`upstream` is probably what you want.  Possible values are:\n> \n\nI would rather talk about 'implicitly given', if it is via a `remote.*.push` config option:\n\n  \tDefines the action `git push` should take if no refspec is\n-\texplicitly given.  Different values are well-suited for\n-\tspecific workflows; for instance, in a purely central workflow\n-\t(i.e. the fetch source is equal to the push destination),\n-\t`upstream` is probably what you want.  Possible values are:\n+\tneither explicitly (on the command-line) nor implicitly (via a\n+\t`remote.*.push` config option) given. Different values are\n+\twell-suited for specific workflows; for instance, in a purely\n+\tcentral workflow (i.e. the fetch source is equal to the push\n+\tdestination), `upstream` is probably what you want.  Possible\n+\tvalues are:\n\n\nBert\n"},{"id":"390536","messageId":"20200127070238.GA32427@coredump.intra.peff.net","threadId":"52691","inReplyTo":"d8007df9-002b-6db1-4769-d6bf8c338cdf@googlemail.com","subject":"Re: [PATCH] doc: clarify \"explicitly given\" in push.default","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-01-27T07:02:38Z","receivedAt":"2020-01-27T07:02:41Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jan 27, 2020 at 08:00:22AM +0100, Bert Wesarg wrote:\n\n> > diff --git a/Documentation/config/push.txt b/Documentation/config/push.txt\n> > index 0a0e000569..554ab44b4c 100644\n> > --- a/Documentation/config/push.txt\n> > +++ b/Documentation/config/push.txt\n> > @@ -1,6 +1,7 @@\n> >   push.default::\n> >   \tDefines the action `git push` should take if no refspec is\n> > -\texplicitly given.  Different values are well-suited for\n> > +\texplicitly given (either on the command-line or via a\n> > +\t`remote.*.push` config option). Different values are well-suited for\n> >   \tspecific workflows; for instance, in a purely central workflow\n> >   \t`upstream` is probably what you want.  Possible values are:\n> > \n> \n> I would rather talk about 'implicitly given', if it is via a `remote.*.push` config option:\n> \n>  \tDefines the action `git push` should take if no refspec is\n> -\texplicitly given.  Different values are well-suited for\n> -\tspecific workflows; for instance, in a purely central workflow\n> -\t(i.e. the fetch source is equal to the push destination),\n> -\t`upstream` is probably what you want.  Possible values are:\n> +\tneither explicitly (on the command-line) nor implicitly (via a\n> +\t`remote.*.push` config option) given. Different values are\n> +\twell-suited for specific workflows; for instance, in a purely\n> +\tcentral workflow (i.e. the fetch source is equal to the push\n> +\tdestination), `upstream` is probably what you want.  Possible\n> +\tvalues are:\n\nYeah, that sounds fine. Want to wrap it up with as a patch with a commit\nmessage?\n\n-Peff\n"},{"id":"390547","messageId":"1113893dd36a1e8cf72331dd01f36206b44f45ad.1580116685.git.bert.wesarg@googlemail.com","threadId":"52691","inReplyTo":"20200127070238.GA32427@coredump.intra.peff.net","subject":"[PATCH] doc: clarify \"explicitly given\" in push.default","fromName":"Bert Wesarg","fromEmail":"bert.wesarg@googlemail.com","sentAt":"2020-01-27T09:25:03Z","receivedAt":"2020-01-27T09:25:08Z","isPatch":true,"sender":{"key":"bert.wesarg@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/111934?v=4"},"body":"The documentation for push.default mentions that it is used if no\nrefspec is \"explicitly given\". Let's clarify that giving a refspec on\nthe command-line _or_ in the config will override it.\n\nSigned-off-by: Jeff King <peff@peff.net>\nSigned-off-by: Bert Wesarg <bert.wesarg@googlemail.com>\n---\n Documentation/config/push.txt | 10 ++++++----\n 1 file changed, 6 insertions(+), 4 deletions(-)\n\nCc: peff@peff.net\n\ndiff --git a/Documentation/config/push.txt b/Documentation/config/push.txt\nindex 0a0e000569..d560362c9a 100644\n--- a/Documentation/config/push.txt\n+++ b/Documentation/config/push.txt\n@@ -1,9 +1,11 @@\n push.default::\n \tDefines the action `git push` should take if no refspec is\n-\texplicitly given.  Different values are well-suited for\n-\tspecific workflows; for instance, in a purely central workflow\n-\t(i.e. the fetch source is equal to the push destination),\n-\t`upstream` is probably what you want.  Possible values are:\n+\tneither explicitly (on the command-line) nor implicitly (via a\n+\t`remote.*.push` config option) given.  Different values are\n+\twell-suited for specific workflows; for instance, in a purely\n+\tcentral workflow (i.e. the fetch source is equal to the push\n+\tdestination), `upstream` is probably what you want.  Possible\n+\tvalues are:\n +\n --\n \n-- \n2.24.1.497.g9abd7b20b4.dirty\n\n"},{"id":"390578","messageId":"dfcf0201-b634-2274-f041-a6ec4491825a@googlemail.com","threadId":"52691","inReplyTo":"d8007df9-002b-6db1-4769-d6bf8c338cdf@googlemail.com","subject":"Re: [PATCH] doc: clarify \"explicitly given\" in push.default","fromName":"Bert Wesarg","fromEmail":"bert.wesarg@googlemail.com","sentAt":"2020-01-27T19:48:01Z","receivedAt":"2020-01-27T19:48:06Z","isPatch":true,"sender":{"key":"bert.wesarg@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/111934?v=4"},"body":"Dear Jeff,\n\nOn 27.01.20 08:00, Bert Wesarg wrote:\n> On 25.01.20 21:05, Jeff King wrote:\n>> On Sat, Jan 25, 2020 at 08:38:04AM +0100, Bert Wesarg wrote:\n>>\n>>> thanks for this pointer. My initial pointer was the help for push.default:\n>>>\n>>>   From git-config(1):\n>>>\n>>>         push.default\n>>>             Defines the action git push should take if no refspec is explicitly\n>>>             given. Different values are well-suited for specific workflows; for\n>>>\n>>> Thus I expected, that this takes effect, when just calling 'git push'.\n>>\n>> Yeah, I agree \"explicitly given\" is vague there. Perhaps the patch below\n>> is worth doing?\n>>\n>>> What I actually want to achieve, is to track a remote branch with a\n>>> different name locally, but 'git push' should nevertheless push to\n>>> tracked remote branch.\n>>>\n>>> In my example above, befor adding the 'push.origin.push' refspec, rename the branch:\n>>>\n>>>      $ git branch -m local\n>>>      $ git push --dry-run\n>>>        To ../bare.git\n>>>         * [new branch]      local -> local\n>>>\n>>> Is it possible that this pushes to the tracked branch automatically,\n>>> and because I have multiple such branches, without the use of a push\n>>> refspec.\n>>\n>> I think if push.default is set to \"upstream\" then it would do what you\n>> want as long as you set the upstream of \"local\" (e.g., by doing \"git\n>> branch --set-upstream-to=origin/master local).\n> \n> Thanks. This pushes only the current branch and honors the 'rename'.\n\nwhile this works …\n\n> \n>>\n>> There's another way of doing this, which is when you have a \"triangular\"\n>> flow: you might pull changes from origin/master into your local branch\n>> X, but then push them elsewhere. Usually this would be pushing to a\n>> branch named X on a different remote than origin (e.g., your public fork\n>> of upstream on a server). And for that you can set branch.X.pushRemote.\n\n… 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:\n\n     $ git push triangular\n     fatal: You are pushing to remote 'triangular', which is not the upstream of\n     your current branch 'X', without telling me what to push\n     to update which remote branch.\n\nIn 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?\n\nBest,\nBert\n"},{"id":"390582","messageId":"4715ac3d-0d85-c8f9-4cc1-cad58d1c1cd6@googlemail.com","threadId":"52691","inReplyTo":"dfcf0201-b634-2274-f041-a6ec4491825a@googlemail.com","subject":"Re: [PATCH] doc: clarify \"explicitly given\" in push.default","fromName":"Bert Wesarg","fromEmail":"bert.wesarg@googlemail.com","sentAt":"2020-01-27T20:53:58Z","receivedAt":"2020-01-27T20:54:03Z","isPatch":true,"sender":{"key":"bert.wesarg@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/111934?v=4"},"body":"\n\nOn 27.01.20 20:48, Bert Wesarg wrote:\n> Dear Jeff,\n> \n> On 27.01.20 08:00, Bert Wesarg wrote:\n>> On 25.01.20 21:05, Jeff King wrote:\n>>> On Sat, Jan 25, 2020 at 08:38:04AM +0100, Bert Wesarg wrote:\n>>>\n>>>> thanks for this pointer. My initial pointer was the help for push.default:\n>>>>\n>>>>   From git-config(1):\n>>>>\n>>>>         push.default\n>>>>             Defines the action git push should take if no refspec is explicitly\n>>>>             given. Different values are well-suited for specific workflows; for\n>>>>\n>>>> Thus I expected, that this takes effect, when just calling 'git push'.\n>>>\n>>> Yeah, I agree \"explicitly given\" is vague there. Perhaps the patch below\n>>> is worth doing?\n>>>\n>>>> What I actually want to achieve, is to track a remote branch with a\n>>>> different name locally, but 'git push' should nevertheless push to\n>>>> tracked remote branch.\n>>>>\n>>>> In my example above, befor adding the 'push.origin.push' refspec, rename the branch:\n>>>>\n>>>>      $ git branch -m local\n>>>>      $ git push --dry-run\n>>>>        To ../bare.git\n>>>>         * [new branch]      local -> local\n>>>>\n>>>> Is it possible that this pushes to the tracked branch automatically,\n>>>> and because I have multiple such branches, without the use of a push\n>>>> refspec.\n>>>\n>>> I think if push.default is set to \"upstream\" then it would do what you\n>>> want as long as you set the upstream of \"local\" (e.g., by doing \"git\n>>> branch --set-upstream-to=origin/master local).\n>>\n>> Thanks. This pushes only the current branch and honors the 'rename'.\n> \n> while this works …\n> \n>>\n>>>\n>>> There's another way of doing this, which is when you have a \"triangular\"\n>>> flow: you might pull changes from origin/master into your local branch\n>>> X, but then push them elsewhere. Usually this would be pushing to a\n>>> branch named X on a different remote than origin (e.g., your public fork\n>>> of upstream on a server). And for that you can set branch.X.pushRemote.\n> \n> … 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:\n> \n>      $ git push triangular\n>      fatal: You are pushing to remote 'triangular', which is not the upstream of\n>      your current branch 'X', without telling me what to push\n>      to update which remote branch.\n> \n> 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?\n\nFalling back to simple/current seems to work for my case:\n\ndiff --git a/builtin/push.c b/builtin/push.c\nindex 6dbf0f0bb7..6b2fac7977 100644 builtin/push.c\n--- a/builtin/push.c\n+++ b/builtin/push.c\n@@ -259,7 +259,10 @@ static void setup_default_push_refspecs(struct remote *remote)\n                 break;\n  \n         case PUSH_DEFAULT_UPSTREAM:\n-               setup_push_upstream(remote, branch, triangular, 0);\n+               if (triangular)\n+                       setup_push_current(remote, branch);\n+               else\n+                       setup_push_upstream(remote, branch, triangular, 0);\n                 break;\n  \n         case PUSH_DEFAULT_CURRENT:\n\nIt has some fallouts in the test suite, obviously. But is this something we should pursue at all?\n\nBert\n"},{"id":"390593","messageId":"20200127231209.GC19360@coredump.intra.peff.net","threadId":"52691","inReplyTo":"1113893dd36a1e8cf72331dd01f36206b44f45ad.1580116685.git.bert.wesarg@googlemail.com","subject":"Re: [PATCH] doc: clarify \"explicitly given\" in push.default","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-01-27T23:12:09Z","receivedAt":"2020-01-27T23:12:12Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jan 27, 2020 at 10:25:03AM +0100, Bert Wesarg wrote:\n\n> The documentation for push.default mentions that it is used if no\n> refspec is \"explicitly given\". Let's clarify that giving a refspec on\n> the command-line _or_ in the config will override it.\n\nYep, looks good to me.\n\n> Signed-off-by: Jeff King <peff@peff.net>\n> Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>\n\nI don't know that we need my S-o-b anymore. The content in this one is\nall you. :) (But certainly I don't mind endorsing it).\n\n-Peff\n"},{"id":"390595","messageId":"20200127231459.GD19360@coredump.intra.peff.net","threadId":"52691","inReplyTo":"dfcf0201-b634-2274-f041-a6ec4491825a@googlemail.com","subject":"Re: [PATCH] doc: clarify \"explicitly given\" in push.default","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-01-27T23:14:59Z","receivedAt":"2020-01-27T23:15:02Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jan 27, 2020 at 08:48:01PM +0100, Bert Wesarg wrote:\n\n> > > There's another way of doing this, which is when you have a \"triangular\"\n> > > flow: you might pull changes from origin/master into your local branch\n> > > X, but then push them elsewhere. Usually this would be pushing to a\n> > > branch named X on a different remote than origin (e.g., your public fork\n> > > of upstream on a server). And for that you can set branch.X.pushRemote.\n> \n> … it does not play well if you have have both flows in one repository.\n> And I do have both flows. I track the upstream 'master' in the local\n> branch 'Y' and I have also a branch 'X' which is based on 'Y' but\n> should be pushed to a different remote as branch 'Y'. I have\n> configured 'branch.X.pushRemote = triangular' but with 'push.default'\n> set to 'upstream' I get this when:\n> \n>     $ git push triangular\n>     fatal: You are pushing to remote 'triangular', which is not the upstream of\n>     your current branch 'X', without telling me what to push\n>     to update which remote branch.\n> \n> In this simple case, without a renaming, I would expect that 'git\n> push' just works. May be just fallback to 'simple' if 'upstream' does\n> not resolve to a fully qualified push?\n\nI thought the point of \"simple\" was to be even more restrictive than\n\"upstream\".\n\nAt any rate, your setup is sufficiently complicated that I think you'd\nbe better off adding a branch.X.pushRef feature (essentially a refspec\nto be used just on branch X, though since the source side is implied,\nit's really just a destination ref).\n\n-Peff\n"},{"id":"390666","messageId":"CAKPyHN3g9egige5Sac9nogu7JA2n5wov_mDabsj80Ti+kVH6Cw@mail.gmail.com","threadId":"52691","inReplyTo":"20200127231459.GD19360@coredump.intra.peff.net","subject":"Re: [PATCH] doc: clarify \"explicitly given\" in push.default","fromName":"Bert Wesarg","fromEmail":"bert.wesarg@googlemail.com","sentAt":"2020-01-28T20:48:02Z","receivedAt":"2020-01-28T20:48:15Z","isPatch":true,"sender":{"key":"bert.wesarg@googlemail.com","avatar":"https://avatars.githubusercontent.com/u/111934?v=4"},"body":"On Tue, Jan 28, 2020 at 12:15 AM Jeff King <peff@peff.net> wrote:\n>\n> On Mon, Jan 27, 2020 at 08:48:01PM +0100, Bert Wesarg wrote:\n>\n> > > > There's another way of doing this, which is when you have a \"triangular\"\n> > > > flow: you might pull changes from origin/master into your local branch\n> > > > X, but then push them elsewhere. Usually this would be pushing to a\n> > > > branch named X on a different remote than origin (e.g., your public fork\n> > > > of upstream on a server). And for that you can set branch.X.pushRemote.\n> >\n> > … it does not play well if you have have both flows in one repository.\n> > And I do have both flows. I track the upstream 'master' in the local\n> > branch 'Y' and I have also a branch 'X' which is based on 'Y' but\n> > should be pushed to a different remote as branch 'Y'. I have\n> > configured 'branch.X.pushRemote = triangular' but with 'push.default'\n> > set to 'upstream' I get this when:\n> >\n> >     $ git push triangular\n> >     fatal: You are pushing to remote 'triangular', which is not the upstream of\n> >     your current branch 'X', without telling me what to push\n> >     to update which remote branch.\n> >\n> > In this simple case, without a renaming, I would expect that 'git\n> > push' just works. May be just fallback to 'simple' if 'upstream' does\n> > not resolve to a fully qualified push?\n>\n> I thought the point of \"simple\" was to be even more restrictive than\n> \"upstream\".\n>\n> At any rate, your setup is sufficiently complicated that I think you'd\n> be better off adding a branch.X.pushRef feature (essentially a refspec\n> to be used just on branch X, though since the source side is implied,\n> it's really just a destination ref).\n\nthanks. I will try to come up with a patch.\n\nBert\n\n>\n> -Peff\n"},{"id":"390672","messageId":"xmqqr1zj6xl6.fsf@gitster-ct.c.googlers.com","threadId":"52691","inReplyTo":"1113893dd36a1e8cf72331dd01f36206b44f45ad.1580116685.git.bert.wesarg@googlemail.com","subject":"Re: [PATCH] doc: clarify \"explicitly given\" in push.default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-01-28T22:11:01Z","receivedAt":"2020-01-28T22:11:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Bert Wesarg <bert.wesarg@googlemail.com> writes:\n\n> The documentation for push.default mentions that it is used if no\n> refspec is \"explicitly given\". Let's clarify that giving a refspec on\n> the command-line _or_ in the config will override it.\n>\n> Signed-off-by: Jeff King <peff@peff.net>\n> Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>\n> ---\n>  Documentation/config/push.txt | 10 ++++++----\n>  1 file changed, 6 insertions(+), 4 deletions(-)\n>\n> Cc: peff@peff.net\n>\n> diff --git a/Documentation/config/push.txt b/Documentation/config/push.txt\n> index 0a0e000569..d560362c9a 100644\n> --- a/Documentation/config/push.txt\n> +++ b/Documentation/config/push.txt\n> @@ -1,9 +1,11 @@\n>  push.default::\n>  \tDefines the action `git push` should take if no refspec is\n> -\texplicitly given.  Different values are well-suited for\n> -\tspecific workflows; for instance, in a purely central workflow\n> -\t(i.e. the fetch source is equal to the push destination),\n> -\t`upstream` is probably what you want.  Possible values are:\n> +\tneither explicitly (on the command-line) nor implicitly (via a\n> +\t`remote.*.push` config option) given.  Different values are\n> +\twell-suited for specific workflows; for instance, in a purely\n> +\tcentral workflow (i.e. the fetch source is equal to the push\n> +\tdestination), `upstream` is probably what you want.  Possible\n> +\tvalues are:\n>  +\n>  --\n\nHmph, I am not sure the act of deliberately setting remote.*.push\nconfiguration should not count as an explicit request to Git the\nuser makes.\n\nImmediately follows the above, the description of one of the\npossible values read thusly:\n\n    * `nothing` - do not push anything (error out) unless a refspec is\n      explicitly given. This is primarily meant for people who want to\n      avoid mistakes by always being explicit.\n\nwhich may need an adjustment to keep the whole coherent.  If we\ndecide to say that setting configuration does not count as explicit,\nthen \"unless a refspec is explicitly given\" should be updated to\nmatch.  There may be other mention of \"explicitly\" that needs to be\nadjusted (I didn't hunt for it, but the above one was adjacent and I\ncouldn't not see it).\n\nIf we have to change anything in the description, I would say that\nwe can just drop \"explicitly\".  There are ways to give refspec from\nthe command line, remote.*.push configuration, in .git/remotes file,\netc.  If it were \"if you give refspec from command line, X happens,\nbut giving a config-sourced refspec does not cause X to happen\",\nthat may be a good reason to invent and use a new phrase \"implicitly\ngiven\" that is not used in this paragraph.  But push.default kicks\nin only when *none* of these ways is used to give *any* refspec, so\nthere is not much point differenciating between the command line\nsourced refspec and config sourced refspec in the context of\ndiscussing this feature, I would think.\n"},{"id":"390684","messageId":"20200129024124.GC596379@coredump.intra.peff.net","threadId":"52691","inReplyTo":"xmqqr1zj6xl6.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH] doc: clarify \"explicitly given\" in push.default","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-01-29T02:41:24Z","receivedAt":"2020-01-29T02:41:26Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jan 28, 2020 at 02:11:01PM -0800, Junio C Hamano wrote:\n\n> >  push.default::\n> >  \tDefines the action `git push` should take if no refspec is\n> > -\texplicitly given.  Different values are well-suited for\n> > -\tspecific workflows; for instance, in a purely central workflow\n> > -\t(i.e. the fetch source is equal to the push destination),\n> > -\t`upstream` is probably what you want.  Possible values are:\n> > +\tneither explicitly (on the command-line) nor implicitly (via a\n> > +\t`remote.*.push` config option) given.  Different values are\n> > +\twell-suited for specific workflows; for instance, in a purely\n> > +\tcentral workflow (i.e. the fetch source is equal to the push\n> > +\tdestination), `upstream` is probably what you want.  Possible\n> > +\tvalues are:\n> >  +\n> >  --\n> \n> Hmph, I am not sure the act of deliberately setting remote.*.push\n> configuration should not count as an explicit request to Git the\n> user makes.\n> \n> Immediately follows the above, the description of one of the\n> possible values read thusly:\n> \n>     * `nothing` - do not push anything (error out) unless a refspec is\n>       explicitly given. This is primarily meant for people who want to\n>       avoid mistakes by always being explicit.\n> \n> which may need an adjustment to keep the whole coherent. \n\nYeah, you're right. The term \"explicit\" gets thrown around a fair bit\nthere.\n\nIn that sense my original was slightly better, in that it defines\n\"explicit\" (one might say it even does so...explicitly). But...\n\n> If we have to change anything in the description, I would say that\n> we can just drop \"explicitly\". [...]\n\nYes, I like dropping that word even better.\n\nThough I'd still slightly worry that somebody might not consider\nconfigured refspecs. Saying more clearly \"any refspec no matter where it\ncomes from\" might still be worthwhile. I.e., something like:\n\n  Defines the action `git push` should take if no refspec is given\n  (whether from the command-line, config, or elsewhere).\n\n?\n\n-Peff\n"},{"id":"390697","messageId":"xmqq7e1a7s83.fsf@gitster-ct.c.googlers.com","threadId":"52691","inReplyTo":"20200129024124.GC596379@coredump.intra.peff.net","subject":"Re: [PATCH] doc: clarify \"explicitly given\" in push.default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-01-29T05:21:32Z","receivedAt":"2020-01-29T05:21:40Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> Though I'd still slightly worry that somebody might not consider\n> configured refspecs. Saying more clearly \"any refspec no matter where it\n> comes from\" might still be worthwhile. I.e., something like:\n>\n>   Defines the action `git push` should take if no refspec is given\n>   (whether from the command-line, config, or elsewhere).\n\nThat's 100x better than to say \"explicit\" \"implicit\" etc. and then\nhave readers guess what the adjectives mean or explain what they\nmean in (parentheses).\n\n"},{"id":"390700","messageId":"20200129055355.GB611490@coredump.intra.peff.net","threadId":"52691","inReplyTo":"xmqq7e1a7s83.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH] doc: clarify \"explicitly given\" in push.default","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2020-01-29T05:53:55Z","receivedAt":"2020-01-29T05:53:58Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jan 28, 2020 at 09:21:32PM -0800, Junio C Hamano wrote:\n\n> Jeff King <peff@peff.net> writes:\n> \n> > Though I'd still slightly worry that somebody might not consider\n> > configured refspecs. Saying more clearly \"any refspec no matter where it\n> > comes from\" might still be worthwhile. I.e., something like:\n> >\n> >   Defines the action `git push` should take if no refspec is given\n> >   (whether from the command-line, config, or elsewhere).\n> \n> That's 100x better than to say \"explicit\" \"implicit\" etc. and then\n> have readers guess what the adjectives mean or explain what they\n> mean in (parentheses).\n\nOK, here it is in patch form, then, so we can (hopefully) wrap this up.\n\n-- >8 --\nSubject: [PATCH] doc: drop \"explicitly given\" from push.default description\n\nThe documentation for push.default mentions that it is used if no\nrefspec is \"explicitly given\". Let's drop the notion of \"explicit\" here,\nsince it's vague, and just mention that any refspec from anywhere is\nsufficient to override this.\n\nI've dropped the mention of \"explicitly given\" frmo the definition of\nthe \"nothing\" value right below, too. It's close enough to our\nclarification that it should be obvious we mean the same type of \"given\"\nhere.\n\nSigned-off-by: Jeff King <peff@peff.net>\n---\nNote that there's one other use of the word \"explicit\" in the context,\nbut it is used appropriately. :)\n\n Documentation/config/push.txt | 5 +++--\n 1 file changed, 3 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/config/push.txt b/Documentation/config/push.txt\nindex 0a0e000569..54871f8213 100644\n--- a/Documentation/config/push.txt\n+++ b/Documentation/config/push.txt\n@@ -1,14 +1,15 @@\n push.default::\n \tDefines the action `git push` should take if no refspec is\n-\texplicitly given.  Different values are well-suited for\n+\tgiven (whether from the command-line, config, or elsewhere).\n+\tDifferent values are well-suited for\n \tspecific workflows; for instance, in a purely central workflow\n \t(i.e. the fetch source is equal to the push destination),\n \t`upstream` is probably what you want.  Possible values are:\n +\n --\n \n * `nothing` - do not push anything (error out) unless a refspec is\n-  explicitly given. This is primarily meant for people who want to\n+  given. This is primarily meant for people who want to\n   avoid mistakes by always being explicit.\n \n * `current` - push the current branch to update a branch with the same\n-- \n2.25.0.515.g69a699b7aa\n\n"}]}