From: Peter Wu <peter@lekensteyn.nl>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: [RFC] [PATCH] remote: add new --fetch option for set-url
Date: Wed, 19 Nov 2014 21:48:21 +0100 [thread overview]
Message-ID: <1615472.VQOo6NAl26@al> (raw)
In-Reply-To: <20141119201721.GC10361@peff.net>
On Wednesday 19 November 2014 15:17:21 Jeff King wrote:
> On Wed, Nov 19, 2014 at 08:42:19PM +0100, Peter Wu wrote:
> > git remote set-url --fetch new-fetch-url
> >
> > This is less verbose and is much more intuitive.
>
> I agree your suggestion is a nicer way to do this. I'm just not sure
> that this swapping is all that common an operation. If there were no
> cost, I wouldn't mind. But I'm mostly concerned about the funny,
> non-intuitive behavior of "git remote set-url foo" that is created by
> this.
It is not about swapping, but setting a new fetch while keeping the push
URL intact. Likely not common, but nice to have for the times it is
needed. I am sure there are other features which are not used a lot, but
still exist ;)
> > > would replace both the "url" _and_ "pushurl" values in the third step,
> > > since we did not specify --fetch. But it is in fact identical whether
> > > you run it with "--fetch" or not. That is, it creates a weirdly
> > > non-orthogonal interface.
> >
> > Step three currently only replaces the fetch URL as an explicit push URL
> > (remote.gh.pushurl) is set in step two (and therefore remote.gh.url does
> > not become the implicit push URL).
> >
> > This might be a bug, but since it has been so long this way I was
> > worried that people actually rely on this behavior.
>
> I don't think this is a bug. I think that "git fetch set-url" without
> "--push" is a de-facto "--fetch" already. Which makes sense, as there
> isn't a "--fetch" now (and the "--push" variant and "pushurl" grew after
> the fact, so the "url" option serves double-duty as both the single url
> and the "fetch" half).
>
> And that's what makes the proposed interface funny. Omitting "--fetch"
> is already a de-facto "--fetch", and sometimes the two behave the same,
> and sometimes differently. Calling the option "--keep-push" would be a
> more accurate description, but that is rather clunky.
Before this patch I did not even know that "git remote set-url name url"
would have different user-visible behavior depending on whether a
pushurl is set or not. In my opinion, the proposed functionality does
not make the interface more confusing. Instead, the new option establish
a behavior which is consistent with the existing '--push' name.
(Aside, I intended to name this option "--pull" which seemed more
natural given the opposite direction "--push", but decided to stay
consistent with the "git remote show" terminology.)
I think that your confusion is caused by the meaning of '--push' and
'--fetch'. These options form a group and are not as independent as
"--add". Something like "--change=[push|fetch|all]" would describe the
functionality better:
git remote set-url --change=fetch gh fetchurl
But then the "--push" option becomes redundant.
--
Kind regards,
Peter
https://lekensteyn.nl
next prev parent reply other threads:[~2014-11-19 20:48 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-19 15:18 [RFC] [PATCH] remote: add new --fetch option for set-url Peter Wu
2014-11-19 19:08 ` Jeff King
2014-11-19 19:42 ` Peter Wu
2014-11-19 20:17 ` Jeff King
2014-11-19 20:48 ` Peter Wu [this message]
2014-11-19 20:29 ` Junio C Hamano
2014-11-19 20:52 ` Peter Wu
2014-11-19 21:00 ` Junio C Hamano
2014-11-19 20:58 ` Junio C Hamano
2014-11-19 21:18 ` Junio C Hamano
2014-11-19 21:28 ` Peter Wu
2014-11-24 21:45 ` Peter Wu
2014-11-24 22:04 ` Junio C Hamano
2014-11-24 22:16 ` Peter Wu
2014-11-24 22:22 ` Jeff King
2014-11-24 22:47 ` Peter Wu
2014-11-24 22:54 ` Jeff King
2014-11-24 23:05 ` Junio C Hamano
2014-11-24 23:27 ` Peter Wu
2014-11-25 4:08 ` Jeff King
2014-11-25 4:55 ` Junio C Hamano
2014-11-25 5:01 ` Jeff King
[not found] ` <CAPc5daWh4hnKsTMpaW-TvCmVDfU+rzCezrAHcLgXDG6RVvzXHA@mail.gmail.com>
2014-11-25 11:43 ` Peter Wu
2014-11-25 11:36 ` Peter Wu
2014-11-29 13:31 ` Philip Oakley
2014-12-02 17:45 ` Peter Wu
2014-12-02 23:50 ` 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=1615472.VQOo6NAl26@al \
--to=peter@lekensteyn.nl \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).