{"thread":{"id":"38450","subject":"git push --repo option not working as described in git manual.","startedAt":"2015-01-26T08:21:50Z","lastAt":"2015-01-28T20:55:58Z","messageCount":9,"participants":["Prem","Junio C Hamano","Michael J Gruber","Eric Sunshine","Prem Muthedath"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"255287","messageId":"loom.20150126T091917-791@post.gmane.org","threadId":"38450","inReplyTo":null,"subject":"git push --repo option not working as described in git manual.","fromName":"Prem","fromEmail":"prem.muthedath@gmail.com","sentAt":"2015-01-26T08:21:50Z","receivedAt":"2015-01-26T08:21:50Z","isPatch":false,"sender":{"key":"prem.muthedath@gmail.com","avatar":null},"body":"I am using git 2.2.2 and want to report an issue with git push --repo option.\n\ngit 2.2.2 manual says that git push --repo=public will push to public\nonly if the current branch does not track a remote branch. See\nhttp://git-scm.com/docs/git-push\n\nHowever, I see that git pushes even when the current branch is\ntracking a remote branch.\n\nHere is the test case (push default setting is simple, git version\n2.2.2, Mac OS X 10.10.1):\n1. I have a local branch \"master\".\n2. \"master\" tracks remote branch \"blah/master\". Here \"blah\" is the\nremote repository.\n3. While I am on my local master branch, I run git push --repo=silver\n4. git pushes the local master branch to silver repository.\n5. But per git manual, it shouldn't push to silver, as the local\nbranch is tracking \"blah/master\". So is this broken or am I missing something?\n\n\nHere is another test case (push default setting is simple, git version\n2.2.2, Mac OS X 10.10.1):\n1. I have a local branch \"whoa\".\n2. \"whoa\" tracks remote branch \"origin/whoa\". Here \"origin\" is the\nremote repository.\n3. While I am on my local whoa branch, I run git push --repo=blah\n4. git pushes the local whoa branch to blah repository.\n5. But per git manual, it shouldn't push to blah, as the local branch\nis tracking \"origin/whoa\". So is this broken or am I missing something?\n\n\nAppreciate your help.\n"},{"id":"255293","messageId":"xmqqppa1mrku.fsf@gitster.dls.corp.google.com","threadId":"38450","inReplyTo":"loom.20150126T091917-791@post.gmane.org","subject":"Re: git push --repo option not working as described in git manual.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-01-26T16:31:29Z","receivedAt":"2015-01-26T16:31:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The conclusions from the last time we discussed this [*1*], the last\nword was that\n\n\tgit push $some_opt... --repo=$Repo $more_opt... $args...\n\nis designed to work exactly like\n\n\tgit push $some_opt... $more_opt... $Repo $args...\n\nand the documentation that says otherwise is incorrect. It seems\nthat we never followed up on this after we made that determination,\nwhich is unfortunate. We should at least correct the documentation.\n\n\n[Reference]\n\n*1* http://thread.gmane.org/gmane.comp.version-control.git/110827/focus=111715\n"},{"id":"255323","messageId":"d8bed5c1736a4a291208227b0f54c1039d67f5cc.1422361902.git.git@drmicha.warpmail.net","threadId":"38450","inReplyTo":"xmqqppa1mrku.fsf@gitster.dls.corp.google.com","subject":"[PATCH] git-push.txt: document the behavior of --repo","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2015-01-27T12:35:53Z","receivedAt":"2015-01-27T12:35:53Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"As per the code, the --repo option is equivalent to the \nargument to 'git push'. [It exists for historical reasons, back from the time\nwhen options had to come before arguments.]\n\nSay so. [But not that.]\n\nSigned-off-by: Michael J Gruber \n---\nThanks for digging up the thread, Junio. I never would have thought that\nI had been with the Git community for that long already...\n\n Documentation/git-push.txt | 18 ++----------------\n 1 file changed, 2 insertions(+), 16 deletions(-)\n\ndiff --git a/Documentation/git-push.txt b/Documentation/git-push.txt\nindex ea97576..0ad31c4 100644\n--- a/Documentation/git-push.txt\n+++ b/Documentation/git-push.txt\n@@ -219,22 +219,8 @@ origin +master` to force a push to the `master` branch). See the\n `...` section above for details.\n \n --repo=::\n-\tThis option is only relevant if no argument is\n-\tpassed in the invocation. In this case, 'git push' derives the\n-\tremote name from the current branch: If it tracks a remote\n-\tbranch, then that remote repository is pushed to. Otherwise,\n-\tthe name \"origin\" is used. For this latter case, this option\n-\tcan be used to override the name \"origin\". In other words,\n-\tthe difference between these two commands\n-+\n---------------------------\n-git push public #1\n-git push --repo=public #2\n---------------------------\n-+\n-is that #1 always pushes to \"public\" whereas #2 pushes to \"public\"\n-only if the current branch does not track a remote branch. This is\n-useful if you write an alias or script around 'git push'.\n+\tThis option is equivalent to the argument; the latter\n+\twins if both are specified.\n \n -u::\n --set-upstream::\n-- \n2.3.0.rc1.222.gae238f2\n"},{"id":"255341","messageId":"xmqqvbjskom1.fsf@gitster.dls.corp.google.com","threadId":"38450","inReplyTo":"d8bed5c1736a4a291208227b0f54c1039d67f5cc.1422361902.git.git@drmicha.warpmail.net","subject":"Re: [PATCH] git-push.txt: document the behavior of --repo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-01-27T19:30:46Z","receivedAt":"2015-01-27T19:30:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n> As per the code, the --repo option is equivalent to the \n> argument to 'git push'. [It exists for historical reasons, back from the time\n> when options had to come before arguments.]\n>\n> Say so. [But not that.]\n>\n> Signed-off-by: Michael J Gruber \n> ---\n> Thanks for digging up the thread, Junio. I never would have thought that\n> I had been with the Git community for that long already...\n\n;-)\n\nI think this update will do for now, but in the medium term (read:\nby the end of this year, or earlier if somebody is motivated\nenough), we might want to:\n\n * deprecate --repo= as it is very much no-op these\n days (that is, strike \"But not that\" part above);\n\n * dig deeper what Prem wanted out of their imagined semantics of\n the --repo= option. I suspect that it has something\n to do with support of triangular workflow, and\n\n - it might turn out that there is a better way to do what Prem\n wanted to do without that option but using other existing\n mechanisms [*1*], in which case we can stop there on the code\n side, and clarify how to use those other existing mechanisms in\n the tutorial.\n\n - or it may be that we do not have a good way to achieve what\n Prem wanted to do, and that a *new* option to specify the\n target URL from the command line, like Prem used the --repo\n option may turn out to be the best way forward [*2*], in which\n case a code update may become necessary.\n\nThanks.\n\n\n\n[Footnotes]\n\n *1* For example, in 1.8.3 we saw some changes around triangular\n \"pull from one place, push to another place\" workflow with\n remote.pushdefault configuration, and branch.*.pushremote lets\n the users control this even at a branch level.\n\n *2* I say \"may turn out to be\" because we cannot tell if that is\n the best solution until we know what was really what Prem\n wanted to do---we may be looking at an XY problem after all.\n"},{"id":"255350","messageId":"CAPig+cQCf+vKbZ5ydFSNmGCUvmCkQW-DEPhO1JAAap1VorhXsA@mail.gmail.com","threadId":"38450","inReplyTo":"d8bed5c1736a4a291208227b0f54c1039d67f5cc.1422361902.git.git@drmicha.warpmail.net","subject":"Re: [PATCH] git-push.txt: document the behavior of --repo","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2015-01-27T22:07:19Z","receivedAt":"2015-01-27T22:07:19Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Tue, Jan 27, 2015 at 7:35 AM, Michael J Gruber\n wrote:\n> As per the code, the --repo option is equivalent to the \n> argument to 'git push'. [It exists for historical reasons, back from the time\n> when options had to come before arguments.]\n>\n> Say so. [But not that.]\n>\n> Signed-off-by: Michael J Gruber \n> ---\n> diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt\n> index ea97576..0ad31c4 100644\n> --- a/Documentation/git-push.txt\n> +++ b/Documentation/git-push.txt\n> @@ -219,22 +219,8 @@ origin +master` to force a push to the `master` branch). See the\n> `...` section above for details.\n>\n> --repo=::\n> - This option is only relevant if no argument is\n> - passed in the invocation. In this case, 'git push' derives the\n> - remote name from the current branch: If it tracks a remote\n> - branch, then that remote repository is pushed to. Otherwise,\n> - the name \"origin\" is used. For this latter case, this option\n> - can be used to override the name \"origin\". In other words,\n> - the difference between these two commands\n> -+\n> ---------------------------\n> -git push public #1\n> -git push --repo=public #2\n> ---------------------------\n> -+\n> -is that #1 always pushes to \"public\" whereas #2 pushes to \"public\"\n> -only if the current branch does not track a remote branch. This is\n> -useful if you write an alias or script around 'git push'.\n> + This option is equivalent to the argument; the latter\n> + wins if both are specified.\n\nTo what does \"latter\" refer in this case? (I presume it means the\nstandalone argument, though the text feels ambiguous.)\n\nAlso, both the standalone argument and the right-hand-side of --repo=\nare spelled \"\", so there may be potential for confusion\nwhen talking about (despite the subsequent \"argument\").\nPerhaps qualifying it as \"_standalone_ argument\" might\nhelp.\n\n> -u::\n> --set-upstream::\n> --\n> 2.3.0.rc1.222.gae238f2\n"},{"id":"255368","messageId":"CAHQ-GLCBXFtLxDME83Qxbw_w1sPaKONzC8xrboh9v+jtEb7-Vw@mail.gmail.com","threadId":"38450","inReplyTo":"CAPig+cQCf+vKbZ5ydFSNmGCUvmCkQW-DEPhO1JAAap1VorhXsA@mail.gmail.com","subject":"Re: [PATCH] git-push.txt: document the behavior of --repo","fromName":"Prem Muthedath","fromEmail":"prem.muthedath@gmail.com","sentAt":"2015-01-28T16:20:13Z","receivedAt":"2015-01-28T16:20:13Z","isPatch":true,"sender":{"key":"prem.muthedath@gmail.com","avatar":null},"body":"Hello Junio, Michael -- thanks much for clearing this up for me.\nAppreciate your time.\n\nIf the --repo option works just like the argument to git\npush, then I would suggest -- just as Junio has done -- that you\ndeprecate this option. Otherwise, it would confuse users.\n\n\nThere is also a minor typo that I noticed in the push documentation\nthat you may want to correct. In the \"Examples\" section in git push\nmanual for git 2.2.2 (see paragraph below), instead of\n\"remote.origin.merge\", I think it should be \"branch..merge\"\nconfiguration variable.\n\ngit push origin\nWithout additional configuration, pushes the current branch to the\nconfigured upstream (remote.origin.merge configuration variable) if it\nhas the same name as the current branch, and errors out without\npushing otherwise.\n\n\nThanks,\nPrem\n\nOn Wed, Jan 28, 2015 at 3:37 AM, Eric Sunshine wrote:\n> On Tue, Jan 27, 2015 at 7:35 AM, Michael J Gruber\n> wrote:\n>> As per the code, the --repo option is equivalent to the \n>> argument to 'git push'. [It exists for historical reasons, back from the time\n>> when options had to come before arguments.]\n>>\n>> Say so. [But not that.]\n>>\n>> Signed-off-by: Michael J Gruber \n>> ---\n>> diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt\n>> index ea97576..0ad31c4 100644\n>> --- a/Documentation/git-push.txt\n>> +++ b/Documentation/git-push.txt\n>> @@ -219,22 +219,8 @@ origin +master` to force a push to the `master` branch). See the\n>> `...` section above for details.\n>>\n>> --repo=::\n>> - This option is only relevant if no argument is\n>> - passed in the invocation. In this case, 'git push' derives the\n>> - remote name from the current branch: If it tracks a remote\n>> - branch, then that remote repository is pushed to. Otherwise,\n>> - the name \"origin\" is used. For this latter case, this option\n>> - can be used to override the name \"origin\". In other words,\n>> - the difference between these two commands\n>> -+\n>> ---------------------------\n>> -git push public #1\n>> -git push --repo=public #2\n>> ---------------------------\n>> -+\n>> -is that #1 always pushes to \"public\" whereas #2 pushes to \"public\"\n>> -only if the current branch does not track a remote branch. This is\n>> -useful if you write an alias or script around 'git push'.\n>> + This option is equivalent to the argument; the latter\n>> + wins if both are specified.\n>\n> To what does \"latter\" refer in this case? (I presume it means the\n> standalone argument, though the text feels ambiguous.)\n>\n> Also, both the standalone argument and the right-hand-side of --repo=\n> are spelled \"\", so there may be potential for confusion\n> when talking about (despite the subsequent \"argument\").\n> Perhaps qualifying it as \"_standalone_ argument\" might\n> help.\n>\n>> -u::\n>> --set-upstream::\n>> --\n>> 2.3.0.rc1.222.gae238f2\n"},{"id":"255361","messageId":"xmqqfvauhdfi.fsf@gitster.dls.corp.google.com","threadId":"38450","inReplyTo":"CAPig+cQCf+vKbZ5ydFSNmGCUvmCkQW-DEPhO1JAAap1VorhXsA@mail.gmail.com","subject":"Re: [PATCH] git-push.txt: document the behavior of --repo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-01-28T20:12:49Z","receivedAt":"2015-01-28T20:12:49Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Sunshine writes:\n\n>> + This option is equivalent to the argument; the latter\n>> + wins if both are specified.\n>\n> To what does \"latter\" refer in this case? (I presume it means the\n> standalone argument, though the text feels ambiguous.)\n>\n> Also, both the standalone argument and the right-hand-side of --repo=\n> are spelled \"\", so there may be potential for confusion\n> when talking about (despite the subsequent \"argument\").\n> Perhaps qualifying it as \"_standalone_ argument\" might\n> help.\n\nI didn't find that \"latter\" too hard to understand (I admit that my\nreading stuttered there, though).\n\nI do not think saying \"standalone argument\" there would\nhelp very much, because there is no mention of \"standalone\" around\nthere. The earlier part of the sentence mentions \"option\" and\n\"argument\", so \"the repository specified as an argument is used if\nboth this option and an argument are given\" or something?\n"},{"id":"255367","messageId":"CAPig+cR-45NzCK5mu9d=1o8nss54ShYn1Snexx5rT+En8XeMcA@mail.gmail.com","threadId":"38450","inReplyTo":"xmqqfvauhdfi.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] git-push.txt: document the behavior of --repo","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2015-01-28T20:30:18Z","receivedAt":"2015-01-28T20:30:18Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Wed, Jan 28, 2015 at 3:12 PM, Junio C Hamano wrote:\n> Eric Sunshine writes:\n>\n>>> + This option is equivalent to the argument; the latter\n>>> + wins if both are specified.\n>>\n>> To what does \"latter\" refer in this case? (I presume it means the\n>> standalone argument, though the text feels ambiguous.)\n>>\n>> Also, both the standalone argument and the right-hand-side of --repo=\n>> are spelled \"\", so there may be potential for confusion\n>> when talking about (despite the subsequent \"argument\").\n>> Perhaps qualifying it as \"_standalone_ argument\" might\n>> help.\n>\n> I didn't find that \"latter\" too hard to understand (I admit that my\n> reading stuttered there, though).\n>\n> I do not think saying \"standalone argument\" there would\n> help very much, because there is no mention of \"standalone\" around\n> there. The earlier part of the sentence mentions \"option\" and\n> \"argument\", so \"the repository specified as an argument is used if\n> both this option and an argument are given\" or something?\n\nYes, that addresses the two (minor) ambiguities and sounds fine.\nThinking about it afterward, I came up with this:\n\n This option is equivalent to the argument. If both\n are specified, the command-line argument takes precedence.\n"},{"id":"255374","messageId":"xmqqsieufwv5.fsf@gitster.dls.corp.google.com","threadId":"38450","inReplyTo":"CAPig+cR-45NzCK5mu9d=1o8nss54ShYn1Snexx5rT+En8XeMcA@mail.gmail.com","subject":"Re: [PATCH] git-push.txt: document the behavior of --repo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-01-28T20:55:58Z","receivedAt":"2015-01-28T20:55:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Sunshine writes:\n\n> On Wed, Jan 28, 2015 at 3:12 PM, Junio C Hamano wrote:\n>> Eric Sunshine writes:\n>>\n>>>> + This option is equivalent to the argument; the latter\n>>>> + wins if both are specified.\n>>>\n>>> To what does \"latter\" refer in this case? (I presume it means the\n>>> standalone argument, though the text feels ambiguous.)\n>>>\n>>> Also, both the standalone argument and the right-hand-side of --repo=\n>>> are spelled \"\", so there may be potential for confusion\n>>> when talking about (despite the subsequent \"argument\").\n>>> Perhaps qualifying it as \"_standalone_ argument\" might\n>>> help.\n>>\n>> I didn't find that \"latter\" too hard to understand (I admit that my\n>> reading stuttered there, though).\n>>\n>> I do not think saying \"standalone argument\" there would\n>> help very much, because there is no mention of \"standalone\" around\n>> there. The earlier part of the sentence mentions \"option\" and\n>> \"argument\", so \"the repository specified as an argument is used if\n>> both this option and an argument are given\" or something?\n>\n> Yes, that addresses the two (minor) ambiguities and sounds fine.\n> Thinking about it afterward, I came up with this:\n>\n> This option is equivalent to the argument. If both\n> are specified, the command-line argument takes precedence.\n\nSure, even though I felt a similar stuttering at around 'both' when\nreading it for the first time.\n\nLet me amend using your phrasing and requeue.\n"}]}