Johan Herland [off-list ref] writes:
I don't see how the separate namespaces cause problems here. Also, I don't
know what you're proposing instead, or indeed what other organization of
tags would lead to less confusion.
I'm not against the idea, but one drawback of the separate namespace
is that it introduces complexity for the user. In the common case,
where the user may fetch the same tag from various sources, there
will still be several refs (probably listed by "git tag" ?), and this
may confuse the user.
Another question is what happens when you push. With branches,
fetching XXX fetches in origin/XXX, but pushing YYY does push to YYY.
This asymetry between push and pull works well because most of the
time, if we have a origin/XXX branch, we also have XXX (with
origin/XXX as upstream).
For tags, it's clearly different. If I have origin/v1.7.4, I don't see
much reason to have _also_ v1.7.4 as a local tag. And if I have only
origin/v1.7.4 and push it as origin/v1.7.4, then someone pulling from
it will get origin/origin/v1.7.4, and so on.
So, my feeling is that the "separate namespace" should not be
automatic.
For example, today, git.git repo contains tags like v1.7.4 and others
like gitgui-0.13.0, which is clearly a handmade namespace, where a
real namespace would be better. That would make a lot of sence to me
if Junio had something like
[remote "git-gui"]
url = ...
fetch = +refs/heads/*:refs/remotes/git-gui/*
fetch = +refs/tags/*:refs/tags/remotes/git-gui/*
or whatever other syntax, so that git-gui's tags be automatically
fetched into the right namespace (with no warning in case of
duplicate).
But OTOH, I don't want to have several namespaces in my git repo even
if I configure several remotes to fetch from. In this case, duplicate
tags are just redundancy if they point to the same object, and a real
conflict I want to know about immediately otherwise.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
(resend without HTML part; I apologize for the inconvenience)
On Sunday 06 February 2011, Matthieu Moy wrote:
Johan Herland [off-list ref] writes:
quoted
I don't see how the separate namespaces cause problems here. Also, I
don't know what you're proposing instead, or indeed what other
organization of tags would lead to less confusion.
I'm not against the idea, but one drawback of the separate namespace
is that it introduces complexity for the user. In the common case,
where the user may fetch the same tag from various sources, there
will still be several refs (probably listed by "git tag" ?), and this
may confuse the user.
If the user is confused by putting remote tags in separate namespaces, then
the user is likely also confused by the current practice of putting remote
_branches_ in separate namespaces. My point is that by strictly delineating
the boundaries between what is local and what belongs to a given remote, I
hope we could help some newbies past the local vs. remote confusion that
often manifests itself when migrating from a centralized VCS to a DVCS.
Another question is what happens when you push. With branches,
fetching XXX fetches in origin/XXX, but pushing YYY does push to YYY.
This asymetry between push and pull works well because most of the
time, if we have a origin/XXX branch, we also have XXX (with
origin/XXX as upstream).
I look at it differently: "fetch" is for information discovery (i.e. "I want
to know what's happened on the remote"), while pull/push is about making
real changes to local/remote branches.
For tags, it's clearly different. If I have origin/v1.7.4, I don't see
much reason to have _also_ v1.7.4 as a local tag. And if I have only
origin/v1.7.4 and push it as origin/v1.7.4, then someone pulling from
it will get origin/origin/v1.7.4, and so on.
Wrong. If you have origin/v1.7.4, it's because v1.7.4 already exists in the
origin remote, so there's no point in trying to push it back. On the other
hand, if you have v1.7.4 locally (but not origin/v1.7.4), you should
(assuming this is intended to be a public tag) consider pushing it to the
"origin" remote, thus causing origin/v1.7.4 to appear in your repo.
So, my feeling is that the "separate namespace" should not be
automatic.
For example, today, git.git repo contains tags like v1.7.4 and others
like gitgui-0.13.0, which is clearly a handmade namespace, where a
real namespace would be better. That would make a lot of sence to me
if Junio had something like
[remote "git-gui"]
url = ...
fetch = +refs/heads/*:refs/remotes/git-gui/*
fetch = +refs/tags/*:refs/tags/remotes/git-gui/*
or whatever other syntax, so that git-gui's tags be automatically
fetched into the right namespace (with no warning in case of
duplicate).
But OTOH, I don't want to have several namespaces in my git repo even
if I configure several remotes to fetch from. In this case, duplicate
tags are just redundancy if they point to the same object, and a real
conflict I want to know about immediately otherwise.
As Nicolas mentioned elsewhere in the thread, having separate tag namespaces
does not prevent us from also warning about ambiguous tag names on fetch.
With separate namespaces, you could probably implement such a warning more
easily as a hook, instead of hacking the fetch code directly.
...Johan
--
Johan Herland, [off-list ref]
www.herland.net
On Mon, Feb 07, 2011 at 12:22:51AM +0100, Johan Herland wrote:
As Nicolas mentioned elsewhere in the thread, having separate tag namespaces
does not prevent us from also warning about ambiguous tag names on fetch.
With separate namespaces, you could probably implement such a warning more
easily as a hook, instead of hacking the fetch code directly.
Since when we started to handle the common case by forcing each user to
write some hook (BTW, which one?), while having an uncommon case as the
default? It makes no sense. And Nicolas suggested something different --
always warn on fetch, which means there will be warnings in your case
where you have two projects in one repo.
Dmitry