All of lore.kernel.org
 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 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.