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

Michael J Gruber [off-list ref] 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 <redacted>
---
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.