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

Peter Wu [off-list ref] 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.