git push --repo option not working as described in git manual.

git push --repo option not working as described in git manual.

[Prem]

I am using git 2.2.2 and want to report an issue with git push --repo option.

git 2.2.2 manual says that git push --repo=public will push to public
only if the current branch does not track a remote branch.  See
http://git-scm.com/docs/git-push

However, I see that git pushes even when the current branch is
tracking a remote branch.

Here is the test case (push default setting is simple, git version
2.2.2, Mac OS X 10.10.1):
1. I have a local branch "master".
2. "master" tracks remote branch "blah/master".  Here "blah" is the
remote repository.
3. While I am on my local master branch, I run git push --repo=silver
4. git pushes the local master branch to silver repository.
5. But per git manual, it shouldn't push to silver, as the local
branch is tracking "blah/master". So is this broken or am I missing something?


Here is another test case (push default setting is simple, git version
2.2.2, Mac OS X 10.10.1):
1. I have a local branch "whoa".
2. "whoa" tracks remote branch "origin/whoa".  Here "origin" is the
remote repository.
3. While I am on my local whoa branch, I run git push --repo=blah
4. git pushes the local whoa branch to blah repository.
5. But per git manual, it shouldn't push to blah, as the local branch
is tracking "origin/whoa".  So is this broken or am I missing something?


Appreciate your help.

Re: git push --repo option not working as described in git manual.

[Junio C Hamano]

The conclusions from the last time we discussed this [*1*], the last
word was that

	git push $some_opt... --repo=$Repo $more_opt... $args...

is designed to work exactly like

	git push $some_opt... $more_opt... $Repo $args...

and the documentation that says otherwise is incorrect.  It seems
that we never followed up on this after we made that determination,
which is unfortunate.  We should at least correct the documentation.


[Reference]

*1* http://thread.gmane.org/gmane.comp.version-control.git/110827/focus=111715

[PATCH] git-push.txt: document the behavior of --repo

[Michael J Gruber]

As per the code, the --repo <repo> option is equivalent to the <repo>
argument to 'git push'. [It exists for historical reasons, back from the time
when options had to come before arguments.]

Say so. [But not that.]

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
Thanks for digging up the thread, Junio. I never would have thought that
I had been with the Git community for that long already...

 Documentation/git-push.txt | 18 ++----------------
 1 file changed, 2 insertions(+), 16 deletions(-)

diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index ea97576..0ad31c4 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -219,22 +219,8 @@ origin +master` to force a push to the `master` branch). See the
 `<refspec>...` section above for details.
 
 --repo=<repository>::
-	This option is only relevant if no <repository> argument is
-	passed in the invocation. In this case, 'git push' derives the
-	remote name from the current branch: If it tracks a remote
-	branch, then that remote repository is pushed to. Otherwise,
-	the name "origin" is used. For this latter case, this option
-	can be used to override the name "origin". In other words,
-	the difference between these two commands
-+
---------------------------
-git push public         #1
-git push --repo=public  #2
---------------------------
-+
-is that #1 always pushes to "public" whereas #2 pushes to "public"
-only if the current branch does not track a remote branch. This is
-useful if you write an alias or script around 'git push'.
+	This option is equivalent to the <repository> argument; the latter
+	wins if both are specified.
 
 -u::
 --set-upstream::
-- 
2.3.0.rc1.222.gae238f2

Re: [PATCH] git-push.txt: document the behavior of --repo

[Junio C Hamano]

Michael J Gruber <git@drmicha.warpmail.net> writes:

> As per the code, the --repo <repo> option is equivalent to the <repo>
> argument to 'git push'. [It exists for historical reasons, back from the time
> when options had to come before arguments.]
>
> Say so. [But not that.]
>
> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
> ---
> Thanks for digging up the thread, Junio. I never would have thought that
> I had been with the Git community for that long already...

;-)

I think this update will do for now, but in the medium term (read:
by the end of this year, or earlier if somebody is motivated
enough), we might want to:

 * deprecate --repo=<repository> as it is very much no-op these
   days (that is, strike "But not that" part above);

 * dig deeper what Prem wanted out of their imagined semantics of
   the --repo=<repository> option.  I suspect that it has something
   to do with support of triangular workflow, and

   - it might turn out that there is a better way to do what Prem
     wanted to do without that option but using other existing
     mechanisms [*1*], in which case we can stop there on the code
     side, and clarify how to use those other existing mechanisms in
     the tutorial.

   - or it may be that we do not have a good way to achieve what
     Prem wanted to do, and that a *new* option to specify the
     target URL from the command line, like Prem used the --repo
     option may turn out to be the best way forward [*2*], in which
     case a code update may become necessary.

Thanks.



[Footnotes]

 *1* For example, in 1.8.3 we saw some changes around triangular
     "pull from one place, push to another place" workflow with
     remote.pushdefault configuration, and branch.*.pushremote lets
     the users control this even at a branch level.

 *2* I say "may turn out to be" because we cannot tell if that is
     the best solution until we know what was really what Prem
     wanted to do---we may be looking at an XY problem after all.

Re: [PATCH] git-push.txt: document the behavior of --repo

[Eric Sunshine]

On Tue, Jan 27, 2015 at 7:35 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> As per the code, the --repo <repo> option is equivalent to the <repo>
> argument to 'git push'. [It exists for historical reasons, back from the time
> when options had to come before arguments.]
>
> Say so. [But not that.]
>
> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
> ---
> diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
> index ea97576..0ad31c4 100644
> --- a/Documentation/git-push.txt
> +++ b/Documentation/git-push.txt
> @@ -219,22 +219,8 @@ origin +master` to force a push to the `master` branch). See the
>  `<refspec>...` section above for details.
>
>  --repo=<repository>::
> -       This option is only relevant if no <repository> argument is
> -       passed in the invocation. In this case, 'git push' derives the
> -       remote name from the current branch: If it tracks a remote
> -       branch, then that remote repository is pushed to. Otherwise,
> -       the name "origin" is used. For this latter case, this option
> -       can be used to override the name "origin". In other words,
> -       the difference between these two commands
> -+
> ---------------------------
> -git push public         #1
> -git push --repo=public  #2
> ---------------------------
> -+
> -is that #1 always pushes to "public" whereas #2 pushes to "public"
> -only if the current branch does not track a remote branch. This is
> -useful if you write an alias or script around 'git push'.
> +       This option is equivalent to the <repository> argument; the latter
> +       wins if both are specified.

To what does "latter" refer in this case? (I presume it means the
standalone <repository> argument, though the text feels ambiguous.)

Also, both the standalone argument and the right-hand-side of --repo=
are spelled "<repository>", so there may be potential for confusion
when talking about <repository> (despite the subsequent "argument").
Perhaps qualifying it as "_standalone_ <repository> argument" might
help.

>  -u::
>  --set-upstream::
> --
> 2.3.0.rc1.222.gae238f2

Re: [PATCH] git-push.txt: document the behavior of --repo

[Prem Muthedath]

Hello Junio, Michael -- thanks much for clearing this up for me.
Appreciate your time.

If the --repo option works just like the <repository> argument to git
push, then I would suggest -- just as Junio has done -- that you
deprecate this option.  Otherwise, it would confuse users.


There is also a minor typo that I noticed in the push documentation
that you may want to correct.  In the "Examples" section in git push
manual for git 2.2.2 (see paragraph below), instead of
"remote.origin.merge", I think it should be "branch.<name>.merge"
configuration variable.

git push origin
Without additional configuration, pushes the current branch to the
configured upstream (remote.origin.merge configuration variable) if it
has the same name as the current branch, and errors out without
pushing otherwise.


Thanks,
Prem

On Wed, Jan 28, 2015 at 3:37 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
> On Tue, Jan 27, 2015 at 7:35 AM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> As per the code, the --repo <repo> option is equivalent to the <repo>
>> argument to 'git push'. [It exists for historical reasons, back from the time
>> when options had to come before arguments.]
>>
>> Say so. [But not that.]
>>
>> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
>> ---
>> diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
>> index ea97576..0ad31c4 100644
>> --- a/Documentation/git-push.txt
>> +++ b/Documentation/git-push.txt
>> @@ -219,22 +219,8 @@ origin +master` to force a push to the `master` branch). See the
>>  `<refspec>...` section above for details.
>>
>>  --repo=<repository>::
>> -       This option is only relevant if no <repository> argument is
>> -       passed in the invocation. In this case, 'git push' derives the
>> -       remote name from the current branch: If it tracks a remote
>> -       branch, then that remote repository is pushed to. Otherwise,
>> -       the name "origin" is used. For this latter case, this option
>> -       can be used to override the name "origin". In other words,
>> -       the difference between these two commands
>> -+
>> ---------------------------
>> -git push public         #1
>> -git push --repo=public  #2
>> ---------------------------
>> -+
>> -is that #1 always pushes to "public" whereas #2 pushes to "public"
>> -only if the current branch does not track a remote branch. This is
>> -useful if you write an alias or script around 'git push'.
>> +       This option is equivalent to the <repository> argument; the latter
>> +       wins if both are specified.
>
> To what does "latter" refer in this case? (I presume it means the
> standalone <repository> argument, though the text feels ambiguous.)
>
> Also, both the standalone argument and the right-hand-side of --repo=
> are spelled "<repository>", so there may be potential for confusion
> when talking about <repository> (despite the subsequent "argument").
> Perhaps qualifying it as "_standalone_ <repository> argument" might
> help.
>
>>  -u::
>>  --set-upstream::
>> --
>> 2.3.0.rc1.222.gae238f2

Re: [PATCH] git-push.txt: document the behavior of --repo

[Junio C Hamano]

Eric Sunshine <sunshine@sunshineco.com> writes:

>> +       This option is equivalent to the <repository> argument; the latter
>> +       wins if both are specified.
>
> To what does "latter" refer in this case? (I presume it means the
> standalone <repository> argument, though the text feels ambiguous.)
>
> Also, both the standalone argument and the right-hand-side of --repo=
> are spelled "<repository>", so there may be potential for confusion
> when talking about <repository> (despite the subsequent "argument").
> Perhaps qualifying it as "_standalone_ <repository> argument" might
> help.

I didn't find that "latter" too hard to understand (I admit that my
reading stuttered there, though).

I do not think saying "standalone <repository> argument" there would
help very much, because there is no mention of "standalone" around
there.  The earlier part of the sentence mentions "option" and
"argument", so "the repository specified as an argument is used if
both this option and an argument are given" or something?

Re: [PATCH] git-push.txt: document the behavior of --repo

[Eric Sunshine]

On Wed, Jan 28, 2015 at 3:12 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Eric Sunshine <sunshine@sunshineco.com> writes:
>
>>> +       This option is equivalent to the <repository> argument; the latter
>>> +       wins if both are specified.
>>
>> To what does "latter" refer in this case? (I presume it means the
>> standalone <repository> argument, though the text feels ambiguous.)
>>
>> Also, both the standalone argument and the right-hand-side of --repo=
>> are spelled "<repository>", so there may be potential for confusion
>> when talking about <repository> (despite the subsequent "argument").
>> Perhaps qualifying it as "_standalone_ <repository> argument" might
>> help.
>
> I didn't find that "latter" too hard to understand (I admit that my
> reading stuttered there, though).
>
> I do not think saying "standalone <repository> argument" there would
> help very much, because there is no mention of "standalone" around
> there.  The earlier part of the sentence mentions "option" and
> "argument", so "the repository specified as an argument is used if
> both this option and an argument are given" or something?

Yes, that addresses the two (minor) ambiguities and sounds fine.
Thinking about it afterward, I came up with this:

    This option is equivalent to the <repository> argument. If both
    are specified, the command-line argument takes precedence.

Re: [PATCH] git-push.txt: document the behavior of --repo

[Junio C Hamano]

Eric Sunshine <sunshine@sunshineco.com> writes:

> On Wed, Jan 28, 2015 at 3:12 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Eric Sunshine <sunshine@sunshineco.com> writes:
>>
>>>> +       This option is equivalent to the <repository> argument; the latter
>>>> +       wins if both are specified.
>>>
>>> To what does "latter" refer in this case? (I presume it means the
>>> standalone <repository> argument, though the text feels ambiguous.)
>>>
>>> Also, both the standalone argument and the right-hand-side of --repo=
>>> are spelled "<repository>", so there may be potential for confusion
>>> when talking about <repository> (despite the subsequent "argument").
>>> Perhaps qualifying it as "_standalone_ <repository> argument" might
>>> help.
>>
>> I didn't find that "latter" too hard to understand (I admit that my
>> reading stuttered there, though).
>>
>> I do not think saying "standalone <repository> argument" there would
>> help very much, because there is no mention of "standalone" around
>> there.  The earlier part of the sentence mentions "option" and
>> "argument", so "the repository specified as an argument is used if
>> both this option and an argument are given" or something?
>
> Yes, that addresses the two (minor) ambiguities and sounds fine.
> Thinking about it afterward, I came up with this:
>
>     This option is equivalent to the <repository> argument. If both
>     are specified, the command-line argument takes precedence.

Sure, even though I felt a similar stuttering at around 'both' when
reading it for the first time.

Let me amend using your phrasing and requeue.