From: Junio C Hamano <hidden> Date: 2016-06-15 23:03:06
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.
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
From: Jeff King <hidden> Date: 2016-06-15 23:03:06
On Mon, Nov 24, 2014 at 11:16:03PM +0100, Peter Wu wrote:
quoted
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.
Right. My original complaint was only that "--fetch" is not as
orthogonal to "--push" (and an optionless set-url) as it could be. I
think the alternatives for going forward are basically:
1. Name it something besides --fetch (but that's rather clunky).
2. Migrate to new behavior, which is what is being discussed here.
Probably needs a transition period?
3. Live with it. Probably address the weirdness in the documentation.
4. Do nothing, drop the patch.
I think I'd be OK with (3), with an appropriate documentation update.
-Peff
On Monday 24 November 2014 17:22:44 Jeff King wrote:
On Mon, Nov 24, 2014 at 11:16:03PM +0100, Peter Wu wrote:
quoted
quoted
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.
Right. My original complaint was only that "--fetch" is not as
orthogonal to "--push" (and an optionless set-url) as it could be. I
think the alternatives for going forward are basically:
1. Name it something besides --fetch (but that's rather clunky).
It is not orthogonal to --push in the config, but the behavior exposed
to the user is orthogonal unless I am missing something?
I can understand that --fetch sounds a bit weird, what about this
natural translation:
"git remote: set the URL (only the fetch one) for NAME to URL"
git remote set-url --only=fetch NAME URL
"git remote: set the URL (only the push one) for NAME to URL"
git remote set-url --only=push NAME URL
(obsoletes --push)
"git remote: set the URL (both) for NAME to URL"
git remote set-url --only=both NAME URL
(it would be nice if --only=both (weird!) can be removed in the
future such that the option is more natural)
"git remote: set the URL for NAME to URL"
git remote set-url NAME URL
(current behavior: YOU git guru knows what I do right?)
2. Migrate to new behavior, which is what is being discussed here.
Probably needs a transition period?
A transition period would also help to solicit feedback.
3. Live with it. Probably address the weirdness in the documentation.
4. Do nothing, drop the patch.
I think I'd be OK with (3), with an appropriate documentation update.
I prefer 1 for now as it avoids the extra manual action I have to take
when changing URLs.
Peter
From: Jeff King <hidden> Date: 2016-06-15 23:03:06
On Mon, Nov 24, 2014 at 11:47:30PM +0100, Peter Wu wrote:
quoted
Right. My original complaint was only that "--fetch" is not as
orthogonal to "--push" (and an optionless set-url) as it could be. I
think the alternatives for going forward are basically:
1. Name it something besides --fetch (but that's rather clunky).
It is not orthogonal to --push in the config, but the behavior exposed
to the user is orthogonal unless I am missing something?
My complaint is that you have three possible options to provide: --push,
--fetch, or no option at all. And "--fetch" sometimes behaves like no
option, and sometimes not. Which is the confusing/non-orthogonal part.
I can understand that --fetch sounds a bit weird, what about this
natural translation:
"git remote: set the URL (only the fetch one) for NAME to URL"
git remote set-url --only=fetch NAME URL
"git remote: set the URL (only the push one) for NAME to URL"
git remote set-url --only=push NAME URL
(obsoletes --push)
"git remote: set the URL (both) for NAME to URL"
git remote set-url --only=both NAME URL
(it would be nice if --only=both (weird!) can be removed in the
future such that the option is more natural)
"git remote: set the URL for NAME to URL"
git remote set-url NAME URL
(current behavior: YOU git guru knows what I do right?)
Yeah, I think that addresses my concern (because it explicitly leaves
no-option as a historical curiosity, and not as an implicit version of
"--both").
quoted
3. Live with it. Probably address the weirdness in the documentation.
4. Do nothing, drop the patch.
I think I'd be OK with (3), with an appropriate documentation update.
I prefer 1 for now as it avoids the extra manual action I have to take
when changing URLs.
I'm not sure if I was clear on (3), but "live with it" was "live with
your original patch". Which I think you would also be happy with.
-Peff
On Monday 24 November 2014 17:54:57 Jeff King wrote:
On Mon, Nov 24, 2014 at 11:47:30PM +0100, Peter Wu wrote:
quoted
I can understand that --fetch sounds a bit weird, what about this
natural translation:
"git remote: set the URL (only the fetch one) for NAME to URL"
git remote set-url --only=fetch NAME URL
"git remote: set the URL (only the push one) for NAME to URL"
git remote set-url --only=push NAME URL
(obsoletes --push)
"git remote: set the URL (both) for NAME to URL"
git remote set-url --only=both NAME URL
(it would be nice if --only=both (weird!) can be removed in the
future such that the option is more natural)
"git remote: set the URL for NAME to URL"
git remote set-url NAME URL
(current behavior: YOU git guru knows what I do right?)
Yeah, I think that addresses my concern (because it explicitly leaves
no-option as a historical curiosity, and not as an implicit version of
"--both").
Ok, I will make a clear note about the default (without --only) behavior
having weird behavior for historical reasons. Are you really OK with
--only=both? It sounds a bit odd (mathematically speaking it is correct
as fetch and push are both partitions that form the whole set if you
ignore the historical behavior).
quoted
quoted
3. Live with it. Probably address the weirdness in the documentation.
4. Do nothing, drop the patch.
I think I'd be OK with (3), with an appropriate documentation update.
I prefer 1 for now as it avoids the extra manual action I have to take
when changing URLs.
I'm not sure if I was clear on (3), but "live with it" was "live with
your original patch". Which I think you would also be happy with.
Oh yes, I misunderstood this one ;)
What about the translations? Should I send a separate patch for that or
can I update all translations at once?
--
Kind regards,
Peter
https://lekensteyn.nl
From: Jeff King <hidden> Date: 2016-06-15 23:03:06
On Tue, Nov 25, 2014 at 12:27:31AM +0100, Peter Wu wrote:
On Monday 24 November 2014 17:54:57 Jeff King wrote:
quoted
On Mon, Nov 24, 2014 at 11:47:30PM +0100, Peter Wu wrote:
quoted
I can understand that --fetch sounds a bit weird, what about this
natural translation:
"git remote: set the URL (only the fetch one) for NAME to URL"
git remote set-url --only=fetch NAME URL
"git remote: set the URL (only the push one) for NAME to URL"
git remote set-url --only=push NAME URL
(obsoletes --push)
"git remote: set the URL (both) for NAME to URL"
git remote set-url --only=both NAME URL
(it would be nice if --only=both (weird!) can be removed in the
future such that the option is more natural)
"git remote: set the URL for NAME to URL"
git remote set-url NAME URL
(current behavior: YOU git guru knows what I do right?)
Yeah, I think that addresses my concern (because it explicitly leaves
no-option as a historical curiosity, and not as an implicit version of
"--both").
Ok, I will make a clear note about the default (without --only) behavior
having weird behavior for historical reasons. Are you really OK with
--only=both? It sounds a bit odd (mathematically speaking it is correct
as fetch and push are both partitions that form the whole set if you
ignore the historical behavior).
Maybe "--operation={push,fetch,both}" would be less odd (though
"--operation" is rather clunky, I could not think of a better word). It
is the conjunction of "--only" an "both" that makes little sense.
However, I think what removed the confusion for me in your --only=both
proposal was the presence of a "both" option, since it made it more
clear that is not what no-option means. So what about just "--push",
"--fetch", and "--both"? Explain the current behavior of no-options in
the documentation as a historical oddity.
That also gives us an easy path forward for changing the behavior.
During the transition period, people should use --push, --fetch, or
--both. Using no-options provides a warning. After a settling period,
the no-option behavior will switch to one of those (presumably --both),
and drop the warning.
You do not have to do the migration path if you don't want to. Adding
"--fetch" and "--both" scratches your itch and sets us up to migrate
later.
What about the translations? Should I send a separate patch for that or
can I update all translations at once?
You do not have to update the translations. When we near a release, the
l10n coordinator will run "make pot" to update po/git.pot with the
strings marked for translation, and then the translators will write
translations for the new strings. You are of course welcome to help with
the translation effort at that stage. :)
Details are in po/README.
-Peff
On Monday 24 November 2014 23:08:26 Jeff King wrote:
However, I think what removed the confusion for me in your --only=both
proposal was the presence of a "both" option, since it made it more
clear that is not what no-option means. So what about just "--push",
"--fetch", and "--both"? Explain the current behavior of no-options in
the documentation as a historical oddity.
Ok, this sounds even better. I have dropped the --only part and made the
options --push, --fetch and --both disjoint (overriding each other). A
patch will follow soon. Maybe it should warn when you try to specify
both options though.
That also gives us an easy path forward for changing the behavior.
During the transition period, people should use --push, --fetch, or
--both. Using no-options provides a warning. After a settling period,
the no-option behavior will switch to one of those (presumably --both),
and drop the warning.
You do not have to do the migration path if you don't want to. Adding
"--fetch" and "--both" scratches your itch and sets us up to migrate
later.
I have documented the historic behavior and mentioned that it is
/possible/ that the option --both becomes default in the future.
quoted
What about the translations? Should I send a separate patch for that or
can I update all translations at once?
You do not have to update the translations. When we near a release, the
l10n coordinator will run "make pot" to update po/git.pot with the
strings marked for translation, and then the translators will write
translations for the new strings. You are of course welcome to help with
the translation effort at that stage.
Details are in po/README.
Well, it is not necessary the translations, but the format of them. The
format
"git remote set-url --delete <name> <url>" has changed to
"git remote set-url [--both | --fetch | --push] --delete <name> <url>"
for example. The old strings are still usable, so I wonder whether I can
make it easier for the i10n maintainer to recognize this change?
--
Kind regards,
Peter
https://lekensteyn.nl
From: Philip Oakley <hidden> Date: 2016-06-15 23:03:08
From: "Peter Wu" <redacted>
Ok, I will make a clear note about the default (without --only)
behavior
having weird behavior for historical reasons. Are you really OK with
--only=both? It sounds a bit odd (mathematically speaking it is
correct
as fetch and push are both partitions that form the whole set if you
ignore the historical behavior).
How about :
s/--only/--direction/
or some suitable abbreviation (--dirn ?)
--
Philip
On Saturday 29 November 2014 13:31:18 Philip Oakley wrote:
From: "Peter Wu" <redacted>
quoted
Ok, I will make a clear note about the default (without --only)
behavior
having weird behavior for historical reasons. Are you really OK with
--only=both? It sounds a bit odd (mathematically speaking it is
correct
as fetch and push are both partitions that form the whole set if you
ignore the historical behavior).
How about :
s/--only/--direction/
or some suitable abbreviation (--dirn ?)