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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 27, 2015, 19:30 UTC
Message-ID: <xmqqvbjskom1.fsf@gitster.dls.corp.google.com>
In-Reply-To: <d8bed5c1736a4a291208227b0f54c1039d67f5cc.1422361902.git.git@drmicha.warpmail.net>

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

Show 10 quoted lines

> 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.