From: Junio C Hamano <hidden> Date: 2016-06-15 22:55:46
Michael J Gruber [off-list ref] writes:
Also there is a conceptual confusion: pushurl is meant to push to the
same repo using a different url, e.g. something authenticated
(https/ssh) for push and something faster/easier for fetch.
That is not necessarily true, depending on the definition of your
"same". Having multiple URLs/PushURLs that refer to physically
different locations, as long as "git push there" immediately
followed by "git fetch here" should work with the repositories that
are conceptually equivalent, is a supported mode of operation. In
fact, they being physically different _was_ the original motivation
of the feature. See 755225d (git builtin "push", 2006-04-29).
The definition of the "immediate" above also depends on your use; it
could be tens of minutes (you may be fetching from git.k.org that
can be reached from the general public, which may be a cname for
multiple machines mirroring a single master.k.org that k.org account
holders push to, and there may be propagation delays). In such a
scenario, your URL may point at the public git.k.org, pushURL may
point at master.k.org, and you may have other pushURLs that point at
other places you use as back-up locations (e.g. git.or.cz or
github.com).
As long as you _mean_ to maintain their contents the same, you can
call them conceptually "the same repo" and your statement becomes
true.
It never was meant to push to several repos.
This is false. It _was_ designed to be used that way from day one.
(I am not saying using it in other ways is an abuse---I am merely
saying that pushing to multiple physically different repositories is
within its scope).
That being said, I don't mind changing the behaviour of set-url.
I do not think we want to change the behaviour of set-url. What
needs to be fixed is the output from "remote -v". It should:
* When there is no pushURL but there is a URL, then show it as
(fetch/push), and you are done;
* When there is one or more pushURLs and a URL, then show the URL
as (fetch), and show pushURLs as (push), and you are done;
* When there are more than one URLs, and there is no pushURL, then
show the first URL as (fetch/push), and the remainder in a
notation that says it is used only for push, but it shouldn't be
the same "(push)"; the user has to be able to distinguish it from
the pushURLs in a repository that also has URLs.
* When there are more than one URLs, and there are one or more
pushURLs, then show the first URL as (fetch), the other URLs
as (unused), and the pushURLs as (push).
Strictly speaking, the last one could be a misconfiguration. If you
have:
[remote "origin"]
url = one
url = two
pushurl = three
pushurl = four
then your "git fetch" will go to one, and "git push" will go to
three and four, and two is never used.
It should also be stressed that the third one a supported
configuration. With
[remote "origin"]
url = one
url = two
your "git fetch" goes to one, and your "git push" will go to one and
two. This is the originally intended use case of 755225d. It is to
push to and fetch from master.k.org (think of "one" above) and in
addition to push to backup.github.com ("two").
From: Michael J Gruber <hidden> Date: 2016-06-15 22:55:47
Junio C Hamano venit, vidit, dixit 15.01.2013 16:53:
Michael J Gruber [off-list ref] writes:
quoted
Also there is a conceptual confusion: pushurl is meant to push to the
same repo using a different url, e.g. something authenticated
(https/ssh) for push and something faster/easier for fetch.
That is not necessarily true, depending on the definition of your
"same". Having multiple URLs/PushURLs that refer to physically
different locations, as long as "git push there" immediately
followed by "git fetch here" should work with the repositories that
are conceptually equivalent, is a supported mode of operation. In
That is my definition of "same", in the sense of "object-and-ref-same"
when "in-sync" (at least regarding all pushed refs; there may be more
there).
fact, they being physically different _was_ the original motivation
of the feature. See 755225d (git builtin "push", 2006-04-29).
I thought it was about unauthenticated git-protocol vs. git+ssh but was
wrong.
The definition of the "immediate" above also depends on your use; it
could be tens of minutes (you may be fetching from git.k.org that
can be reached from the general public, which may be a cname for
multiple machines mirroring a single master.k.org that k.org account
holders push to, and there may be propagation delays). In such a
scenario, your URL may point at the public git.k.org, pushURL may
point at master.k.org, and you may have other pushURLs that point at
other places you use as back-up locations (e.g. git.or.cz or
github.com).
Yes. That is also why we fetch from one fetch URL only, because we
assume they point at the "same" repo and don't need to check.
As long as you _mean_ to maintain their contents the same, you can
call them conceptually "the same repo" and your statement becomes
true.
quoted
It never was meant to push to several repos.
This is false. It _was_ designed to be used that way from day one.
It is very true with me definition of "same" ;)
(I am not saying using it in other ways is an abuse---I am merely
saying that pushing to multiple physically different repositories is
within its scope).
quoted
That being said, I don't mind changing the behaviour of set-url.
I do not think we want to change the behaviour of set-url. What
needs to be fixed is the output from "remote -v". It should:
* When there is no pushURL but there is a URL, then show it as
(fetch/push), and you are done;
* When there is one or more pushURLs and a URL, then show the URL
as (fetch), and show pushURLs as (push), and you are done;
* When there are more than one URLs, and there is no pushURL, then
show the first URL as (fetch/push), and the remainder in a
notation that says it is used only for push, but it shouldn't be
the same "(push)"; the user has to be able to distinguish it from
the pushURLs in a repository that also has URLs.
Maybe "(fetch fallback/push)" if we do use it as a fallback? If we don't
we probably should?
* When there are more than one URLs, and there are one or more
pushURLs, then show the first URL as (fetch), the other URLs
as (unused), and the pushURLs as (push).
Strictly speaking, the last one could be a misconfiguration. If you
have:
[remote "origin"]
url = one
url = two
pushurl = three
pushurl = four
then your "git fetch" will go to one, and "git push" will go to
three and four, and two is never used.
Do we fall back to two if one is unavailable? In any case, people may
use a configuration like that to keep track of mirrors and shuffle
around the fetch lines (rather than commenting/uncommenting) when one
goes offline.
It should also be stressed that the third one a supported
configuration. With
[remote "origin"]
url = one
url = two
your "git fetch" goes to one, and your "git push" will go to one and
two. This is the originally intended use case of 755225d. It is to
push to and fetch from master.k.org (think of "one" above) and in
addition to push to backup.github.com ("two").
From: Michael J Gruber <hidden> Date: 2016-06-15 22:55:47
The current output of "git remote -v" does not distinguish between
explicitly configured push URLs and those coming from fetch lines.
Revise the output so so that URLs are distinguished by their labels:
(fetch): fetch config used for fetching only
(fetch/push): fetch config used for fetching and pushing
(fetch fallback/push): fetch config used for pushing only
(fetch fallback): fetch config which is unused
(push): push config used for pushing
Signed-off-by: Michael J Gruber <redacted>
---
Maybe something like this? It even seems to make the code in get_one_entry
clearer.
I yet have to look at the tests, doc and other git-remote invocations.
builtin/remote.c | 31 +++++++++++++++++--------------
1 file changed, 17 insertions(+), 14 deletions(-)
From: Michael J Gruber <hidden> Date: 2016-06-15 22:55:47
Michael J Gruber venit, vidit, dixit 16.01.2013 11:14:
The current output of "git remote -v" does not distinguish between
explicitly configured push URLs and those coming from fetch lines.
Revise the output so so that URLs are distinguished by their labels:
(fetch): fetch config used for fetching only
(fetch/push): fetch config used for fetching and pushing
(fetch fallback/push): fetch config used for pushing only
(fetch fallback): fetch config which is unused
(push): push config used for pushing
Signed-off-by: Michael J Gruber <redacted>
---
Maybe something like this? It even seems to make the code in get_one_entry
clearer.
I yet have to look at the tests, doc and other git-remote invocations.
Okay, so "git remote show remotename" copied the logic from "git remote
-v" but neither reused the code nor the output format. I guess we'd have
to implement the new logic and keep the old format? Refactoring would
require settling on a common format. Both outputs should be
ui-as-ui-can, but I'm afraid people are still grepping the output in
their scripts :(
Michael
From: John Keeping <hidden> Date: 2016-06-15 22:55:47
On Wed, Jan 16, 2013 at 11:14:48AM +0100, Michael J Gruber wrote:
The current output of "git remote -v" does not distinguish between
explicitly configured push URLs and those coming from fetch lines.
Revise the output so so that URLs are distinguished by their labels:
(fetch): fetch config used for fetching only
(fetch/push): fetch config used for fetching and pushing
(fetch fallback/push): fetch config used for pushing only
(fetch fallback): fetch config which is unused
(push): push config used for pushing
How does this interact with url.<base>.pushInsteadOf?
I have a global rule to convert git:// URLs to ssh:// for pushing:
[url "git@example.com:"]
pushInsteadOf = git://example.com/
With only a URL configured for a remote (no pushURL), I get (with Git
1.8.1):
origin git://example.com/repository.git (fetch)
origin git@example.com:repository.git (push)
From the original discussion in this thread, I think that if I did
"git remote set-url --add --push <url>" it would replace my current push
URL, and the change to "(fetch/push)" doesn't help in this case.
Should there be special handling for pushInsteadOf here?
John
From: Michael J Gruber <hidden> Date: 2016-06-15 22:55:47
John Keeping venit, vidit, dixit 16.01.2013 11:42:
On Wed, Jan 16, 2013 at 11:14:48AM +0100, Michael J Gruber wrote:
quoted
The current output of "git remote -v" does not distinguish between
explicitly configured push URLs and those coming from fetch lines.
Revise the output so so that URLs are distinguished by their labels:
(fetch): fetch config used for fetching only
(fetch/push): fetch config used for fetching and pushing
(fetch fallback/push): fetch config used for pushing only
(fetch fallback): fetch config which is unused
(push): push config used for pushing
How does this interact with url.<base>.pushInsteadOf?
I have a global rule to convert git:// URLs to ssh:// for pushing:
[url "git@example.com:"]
pushInsteadOf = git://example.com/
With only a URL configured for a remote (no pushURL), I get (with Git
1.8.1):
origin git://example.com/repository.git (fetch)
origin git@example.com:repository.git (push)
From the original discussion in this thread, I think that if I did
"git remote set-url --add --push <url>" it would replace my current push
URL, and the change to "(fetch/push)" doesn't help in this case.
Should there be special handling for pushInsteadOf here?
John
Thanks for pointing out this case.
The new code would still list this as two separate URLs because they
really are; whether they come from two config entries or from one being
subject to two different insteadof expansions is completely opaque to
builtin/remote.c, unless remote.c learns to stick that additional info
into struct remote somehow.
In short, the separate listing is correct, but in this case there's no
improvement in readability.
We could still say that (push)InsteadOf is a power feature and we want
to help the "normal" case, but it's a bit half-assed. In the end we
might even have to keep track of insteadof-expansions and display those
also (i.e. "expanded from...")?
Michael
From: John Keeping <hidden> Date: 2016-06-15 22:55:47
On Wed, Jan 16, 2013 at 01:45:36PM +0100, Michael J Gruber wrote:
John Keeping venit, vidit, dixit 16.01.2013 11:42:
quoted
On Wed, Jan 16, 2013 at 11:14:48AM +0100, Michael J Gruber wrote:
quoted
The current output of "git remote -v" does not distinguish between
explicitly configured push URLs and those coming from fetch lines.
Revise the output so so that URLs are distinguished by their labels:
(fetch): fetch config used for fetching only
(fetch/push): fetch config used for fetching and pushing
(fetch fallback/push): fetch config used for pushing only
(fetch fallback): fetch config which is unused
(push): push config used for pushing
How does this interact with url.<base>.pushInsteadOf?
I have a global rule to convert git:// URLs to ssh:// for pushing:
[url "git@example.com:"]
pushInsteadOf = git://example.com/
With only a URL configured for a remote (no pushURL), I get (with Git
1.8.1):
origin git://example.com/repository.git (fetch)
origin git@example.com:repository.git (push)
From the original discussion in this thread, I think that if I did
"git remote set-url --add --push <url>" it would replace my current push
URL, and the change to "(fetch/push)" doesn't help in this case.
Should there be special handling for pushInsteadOf here?
Thanks for pointing out this case.
The new code would still list this as two separate URLs because they
really are; whether they come from two config entries or from one being
subject to two different insteadof expansions is completely opaque to
builtin/remote.c, unless remote.c learns to stick that additional info
into struct remote somehow.
OK. I like the new format, I was just wondering if it was a simple
enhancement to indicate a pushInsteadOf URL specially as well.
In short, the separate listing is correct, but in this case there's no
improvement in readability.
We could still say that (push)InsteadOf is a power feature and we want
to help the "normal" case, but it's a bit half-assed. In the end we
might even have to keep track of insteadof-expansions and display those
also (i.e. "expanded from...")?
Given that it's not a trivial enhancement, I'd accept the argument that
someone who has configured pushInsteadOf can be expected to understand
the underlying git-config semantics of "git remote set-url".
John
From: Phil Hord <hidden> Date: 2016-06-15 22:55:47
On Tue, Jan 15, 2013 at 10:53 AM, Junio C Hamano [off-list ref] wrote:
Michael J Gruber [off-list ref] writes:
quoted
That being said, I don't mind changing the behaviour of set-url.
I do not think we want to change the behaviour of set-url.
I agree with Michael that changing the set-url behavior would be
appropriate here. If I say "--add" this pushUrl, don't I mean to
create an additional url which is pushed to?
I agree that it makes the config situation messy; this is currently a
"clean" sequence, in that it leaves the config unchanged after both
steps are completed:
git remote set-url --add --push origin /tmp/foo
git remote set-url --delete --push origin /tmp/foo
If the behavior is changed like Michael suggested, it would not leave
the config clean (unless heroic steps were taken to keep track). But
I'm not sure that's such a bad thing. In simple command sequences,
the results would be clean and the only behavior change is that the
initial "--add" really acts like "add" and not "replace". But more
complex sequences could be devised which were affected by this change.
I'm curious, Junio. Do you think the set-url behavior is correct
as-is, or that changing it will cause breakage for some workflows, or
that it complicates the operation too much for people who are already
used to the config layout?
Phil
From: Michael J Gruber <hidden> Date: 2016-06-15 22:55:47
Phil Hord venit, vidit, dixit 16.01.2013 17:15:
On Tue, Jan 15, 2013 at 10:53 AM, Junio C Hamano [off-list ref] wrote:
quoted
Michael J Gruber [off-list ref] writes:
quoted
That being said, I don't mind changing the behaviour of set-url.
I do not think we want to change the behaviour of set-url.
I agree with Michael that changing the set-url behavior would be
appropriate here. If I say "--add" this pushUrl, don't I mean to
create an additional url which is pushed to?
I said I wouldn't mind, I didn't vote for it.
I agree that it makes the config situation messy; this is currently a
"clean" sequence, in that it leaves the config unchanged after both
steps are completed:
git remote set-url --add --push origin /tmp/foo
git remote set-url --delete --push origin /tmp/foo
If the behavior is changed like Michael suggested, it would not leave
the config clean (unless heroic steps were taken to keep track). But
I'm not sure that's such a bad thing. In simple command sequences,
the results would be clean and the only behavior change is that the
initial "--add" really acts like "add" and not "replace". But more
complex sequences could be devised which were affected by this change.
I'm curious, Junio. Do you think the set-url behavior is correct
as-is, or that changing it will cause breakage for some workflows, or
that it complicates the operation too much for people who are already
used to the config layout?
For "set url --add --push" on top of a push url only being defaulted
from a fetch url, both behaviours (replace or add, i.e. current or new)
make sense to me. So the questions are:
- Is it worth and possible changing?
- How to best describe it in "remote -v" and "remote show" output?
My patch answered to "no" to the first question and answers the second
one in cases where (push)insteadof is not used to transform one fetch
config into two different urls for fetch and push. I think :)
Michael