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

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

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