public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed

From: Junio C Hamano <gitster@pobox•com>
To: Michael J Gruber <git@drmicha•warpmail.net>
Cc: git@vger•kernel.org, Prem <prem.muthedath@gmail•com>
Subject: Re: [PATCH] git-push.txt: document the behavior of --repo
Date: Tue, 27 Jan 2015 11:30:46 -0800	[thread overview]
Message-ID: <xmqqvbjskom1.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <d8bed5c1736a4a291208227b0f54c1039d67f5cc.1422361902.git.git@drmicha.warpmail.net> (Michael J. Gruber's message of "Tue, 27 Jan 2015 13:35:53 +0100")

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.

next prev parent reply	other threads:[~2015-01-27 19:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqvbjskom1.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox$(echo .)com \
    --cc=git@drmicha$(echo .)warpmail.net \
    --cc=git@vger$(echo .)kernel.org \
    --cc=prem.muthedath@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox