On Monday 24 November 2014 14:04:07 Junio C Hamano wrote: > 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. 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. > > 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 -- 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