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

[Peter Wu <peter@lekensteyn.nl>]

On Monday 24 November 2014 14:04:07 Junio C Hamano wrote:
> Peter Wu <peter@lekensteyn.nl> writes:
> 
> > I propose to add the option --fetch next to --push with the meaning "set
> > the fetch/push URL of remote NAME to URL". Then --fetch --push means
> > "set the fetch and push URL of remote NAME to URL". 
> 
> What would (and "should") the configuration look like after you did
> this?
> 
> 	git remote set-url nick $url1
>         git remote set-url nick --push $url2
>         git remote set-url nick $url3
> 
> Whatever happens without your patch after the above is what the
> current users (i.e. those who do not use the --fetch option) expect,
> so if the behaviour does not change with your patch, then there is
> one less incompatibilities to worry about.
> 
> A new option "--fetch" introducing a different behaviour is
> perfectly fine; existing users who are not using it will not be
> harmed by sudden behaviour change.

As stated before, I took care to avoid backwards incompatibilities. The
command will still work as expected by the users who are aware of this
particular behavior. What I am suggesting (and which is independent of
the patch) is to make the command have a more consistent behavior.
Either it should set the fetch URL, or both the fetch and push URL, but
not vary its behavior depending on whether a push URL is set or not.
That should make the behavior of the command more consistent.

> > In a future git version, this could be made the default option to
> > avoid surprises (which would be backwards incompatible though).
> 
> I am not sure what you mean "by default".  If you mean "set both if
> remote.nick.pushurl does not exist but otherwise update only
> remote.nick.url", then the sequence
> 
> 	git remote set-url nick $url1
>         git remote set-url nick --push $url2
>         git remote set-url nick $url3
> 
> would retain the current behaviour, so it probably is OK.
> 
> If you mean to always set remote.nick.url and remote.nick.pushurl
> pointing at the same value when neither --fetch nor --push is given,
> That would make the sequence behave quite different from what people
> would expect, and you would need to devise a transition plan to
> first start warning when the user did something that will behave
> differently between the current version and the future version
> without changing the behaviour, then switch the behaviour but keep
> warning and finally remove the warning, or something like that.
> 
> And the above three-command sequence may not be the only case where
> the change you are proposing may hurt existing users.

The "default" refers to the behavior of "git remote set-url" in absence
of "--push" and "--fetch" options. A transition period is expected (if
this idea is put forward). Since nobody seems to be bitten by this
option, I am not sure if it really adds much value to make this change
though.
-- 
Kind regards,
Peter
https://lekensteyn.nl