Re: [RFC] [PATCH] remote: add new --fetch option for set-url

[Peter Wu <peter@lekensteyn.nl>]

On Monday 24 November 2014 21:19:16 Junio C Hamano wrote:
> On Mon, Nov 24, 2014 at 9:01 PM, Jeff King <peff@peff.net> wrote:
> > We could also stop making push fall back to fetch. But I think people
> > would find that irritating.

The common case is probably having the same fetch and push URL, so I
think that this should not be changed.

> > I dunno. I think there has always been an implicit "subordinate"
> > relationship between fetch and push URLs, with fetch being the "main"
> > one. Maybe that is so ingrained in me at this point that I do not see a
> > problem with the asymmetry.
> 
> I actually do not have problem with asymmetry/subordinate
> relationship myself, but then why are we adding --fetch to
> complement --push in the first place?
> 
> Or perhaps I am misunderstanding the suggested semantics
> of --both. That "subordinate" relationship really means that
> remote.nick.URL is the one that is used for both directions
> when pushURL is not set.
> 
> I misunderstood that --both would add identical value to both
> remote.nick.URL and remote.nick.pushURL, but that would
> break the implicit subordinate relationship. Is the suggested
> semantics of "set-url --both" to first delete remote.nick.pushURL
> if exists and then to set remote.nick.URL?
> 
> If that is what is being proposed, then I think it makes sense.

Yes, your last understanding is correct. For this feature, try to think
as the user who does not know about the configuration implementation.
That is why the --fetch option was proposed, earlier it did not make
sense to me why a --push option exists, but a --fetch option is missing.

Option '--both' will drop the push URL and result in an implicit
fallback to the fetch URL. It becomes slightly more hairy in the
presence of URL sets (using --add and --delete), but I have also tried
to make that act sensibly).
-- 
Kind regards,
Peter
https://lekensteyn.nl