git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

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