Peter Wu <peter@xxxxxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html