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

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 24, 2014, 22:04 UTC
Message-ID: <xmqqtx1ouug8.fsf@gitster.dls.corp.google.com>
In-Reply-To: <1628833.9HksdDrMW8@al>

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.