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.com \
--cc=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
--cc=prem.muthedath@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.