Re: [1.8.0] Provide proper remote ref namespaces

[Johan Herland <johan@herland.net>]

(resend without HTML part; I apologize for the inconvenience)

On Sunday 06 February 2011, Matthieu Moy wrote:
> Johan Herland <johan@herland.net> 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.

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, <johan@herland.net>
www.herland.net