* git push --repo option not working as described in git manual.
@ 2015-01-26 8:21 Prem
2015-01-26 16:31 ` Junio C Hamano
0 siblings, 1 reply; 9+ messages in thread
From: Prem @ 2015-01-26 8:21 UTC (permalink / raw)
To: git
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: git push --repo option not working as described in git manual.
2015-01-26 8:21 git push --repo option not working as described in git manual Prem
@ 2015-01-26 16:31 ` Junio C Hamano
2015-01-27 12:35 ` [PATCH] git-push.txt: document the behavior of --repo Michael J Gruber
0 siblings, 1 reply; 9+ messages in thread
From: Junio C Hamano @ 2015-01-26 16:31 UTC (permalink / raw)
To: Prem; +Cc: git, Michael J Gruber, Jay Soffian
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] git-push.txt: document the behavior of --repo
2015-01-26 16:31 ` Junio C Hamano
@ 2015-01-27 12:35 ` Michael J Gruber
2015-01-27 19:30 ` Junio C Hamano
2015-01-27 22:07 ` Eric Sunshine
0 siblings, 2 replies; 9+ messages in thread
From: Michael J Gruber @ 2015-01-27 12:35 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Prem
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
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH] git-push.txt: document the behavior of --repo
2015-01-27 12:35 ` [PATCH] git-push.txt: document the behavior of --repo Michael J Gruber
@ 2015-01-27 19:30 ` Junio C Hamano
2015-01-27 22:07 ` Eric Sunshine
1 sibling, 0 replies; 9+ messages in thread
From: Junio C Hamano @ 2015-01-27 19:30 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Prem
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] git-push.txt: document the behavior of --repo
2015-01-27 12:35 ` [PATCH] git-push.txt: document the behavior of --repo Michael J Gruber
2015-01-27 19:30 ` Junio C Hamano
@ 2015-01-27 22:07 ` Eric Sunshine
2015-01-28 16:20 ` Prem Muthedath
2015-01-28 20:12 ` Junio C Hamano
1 sibling, 2 replies; 9+ messages in thread
From: Eric Sunshine @ 2015-01-27 22:07 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Git List, Junio C Hamano, Prem
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] git-push.txt: document the behavior of --repo
2015-01-27 22:07 ` Eric Sunshine
@ 2015-01-28 16:20 ` Prem Muthedath
2015-01-28 20:12 ` Junio C Hamano
1 sibling, 0 replies; 9+ messages in thread
From: Prem Muthedath @ 2015-01-28 16:20 UTC (permalink / raw)
To: Eric Sunshine; +Cc: Michael J Gruber, Git List, Junio C Hamano
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] git-push.txt: document the behavior of --repo
2015-01-27 22:07 ` Eric Sunshine
2015-01-28 16:20 ` Prem Muthedath
@ 2015-01-28 20:12 ` Junio C Hamano
2015-01-28 20:30 ` Eric Sunshine
1 sibling, 1 reply; 9+ messages in thread
From: Junio C Hamano @ 2015-01-28 20:12 UTC (permalink / raw)
To: Eric Sunshine; +Cc: Michael J Gruber, Git List, Prem
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?
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] git-push.txt: document the behavior of --repo
2015-01-28 20:12 ` Junio C Hamano
@ 2015-01-28 20:30 ` Eric Sunshine
2015-01-28 20:55 ` Junio C Hamano
0 siblings, 1 reply; 9+ messages in thread
From: Eric Sunshine @ 2015-01-28 20:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael J Gruber, Git List, Prem
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] git-push.txt: document the behavior of --repo
2015-01-28 20:30 ` Eric Sunshine
@ 2015-01-28 20:55 ` Junio C Hamano
0 siblings, 0 replies; 9+ messages in thread
From: Junio C Hamano @ 2015-01-28 20:55 UTC (permalink / raw)
To: Eric Sunshine; +Cc: Michael J Gruber, Git List, Prem
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2015-01-28 21:07 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-01-26 8:21 git push --repo option not working as described in git manual Prem
2015-01-26 16:31 ` Junio C Hamano
2015-01-27 12:35 ` [PATCH] git-push.txt: document the behavior of --repo Michael J Gruber
2015-01-27 19:30 ` Junio C Hamano
2015-01-27 22:07 ` Eric Sunshine
2015-01-28 16:20 ` Prem Muthedath
2015-01-28 20:12 ` Junio C Hamano
2015-01-28 20:30 ` Eric Sunshine
2015-01-28 20:55 ` Junio C Hamano
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.