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

On Monday 24 November 2014 21:19:16 Junio C Hamano wrote:

On Mon, Nov 24, 2014 at 9:01 PM, Jeff King [off-list ref] wrote:

quoted

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.

quoted

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