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

On Monday 24 November 2014 14:04:07 Junio C Hamano wrote:

Peter Wu [off-list ref] writes:

quoted

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.

quoted

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