On Wednesday 08 June 2011, Nguyen Thai Ngoc Duy wrote: > 2011/6/8 Sverre Rabbelier <srabbelier@xxxxxxxxx>: > > Heya, > > > > [+Peff, Duy, who seemed interested in this] > > > > On Wed, Jun 8, 2011 at 14:52, Ingo Molnar <mingo@xxxxxxx> wrote: > >> So it would be nice to have more separation for remotes - right now > >> they do not sit still in their sandboxes! :-) > > > > Sounds like the "tags should go in their own namespaces in git 1.8.0" > > [0] discussion? :) > > > > [0] > > http://thread.gmane.org/gmane.comp.version-control.git/165799/focus=16 > > 5837 > > A lengthy thread. Does anybody remember the outcome? Was Johan's > proposal OK and only waiting to be implemented, or is there still > unanswered questions? (Sorry for the late answer. Unfortunately, I don't have much Git time these days...) Browsing that thread, it seems my proposal was largely OK. AFAICS there are no major technical problems with moving to the following ref mapping: Remote repo -> Local repo -------------------------------------------------- refs/heads/* refs/remotes/$remote/heads/* refs/tags/* refs/remotes/$remote/tags/* refs/replace/* refs/remotes/$remote/replace/* refs/notes/* refs/remotes/$remote/notes/* There was a fair amount of discussion around whether we really _want_ to put all refs (especially tags) in separate per-remote namespaces, and it seems (both from that thread, and from later threads, like this one) that we _do_ want per-remote namespaces for all refs. That said, there are a couple of outstanding questions/challenges before this can be implemented: 1. How to deal with tag auto-following The tag auto-follow behavior currently depends on the implicit "refs/tags/*:refs/tags/*" refspec, and the "refs/tags/" prefix is presently hardcoded both at the local and remote end. If we want to support auto- follow behavior in the new ref mappings (e.g. specified with a "~" prefix: "~+refs/tags/*:refs/remotes/$remote/tags/*"), we must change code both on the local and remote side. In order to get optimal behavior we will probably also need to make some protocol changes. On the other hand, it is not clear how useful tag auto-following really is. Quoting Peff from the earlier thread ( http://thread.gmane.org/gmane.comp.version-control.git/160503/focus=160726 ): "Now you could argue that auto-follow is not worth the effort. It is somewhat confusing, and I can't think of a time when it ever actually reduced the set of objects I was fetching (as opposed to just fetching all tags). But maybe others have use cases where it matters." Or, quoting Junio further down in the thread ( http://thread.gmane.org/gmane.comp.version-control.git/165799/focus=166694 ): "Also if you give tags a totally separate namespace, I don't see much reason to still give it the "auto-follow" semantics. It is far simpler to explain if you just fetch all of them and be done with it, no?" So far nobody have stood up to defend the current auto-following behavior as a necessary feature. 2. Interpreting/DWIMing refs Changing the ref mappings require a revised set of rules for interpreting shorthand ref names (expanding them into full ref names), and handling ambiguities when they arise: - "foo" should still be usable for "refs/heads/foo", "refs/tags/foo", etc. - "origin/foo" must continue to work, even if "refs/remotes/origin/foo" has now become "refs/remotes/origin/heads/foo". In other words, "foo/bar" where "foo" is a valid remote, must try to resolve "bar" against the refspecs specified for the "foo" remote. - For tag name "foo": "refs/tags/foo" (if exists) is unambiguous. - If "refs/tags/foo" does not exist, tag name "foo" is unambiguous if it exists in one or more "refs/remotes/*/tags/foo" and they all point to the same SHA1. - If "refs/tags/foo" does not exist, and more than one "refs/remotes/*/tags/foo" exist, and they do NOT all point to the same SHA1, then there is an ambiguity. - The user may resolve the ambiguity by creating "refs/tags/foo" pointing to the chosen SHA1 ("refs/tags/foo" takes precedence over "refs/remotes/*/tags/foo"). - The same rules apply to heads, notes, etc. - Extra care must be taken across different "types" of refs, depending on the context. I.e. in some situations we might want to prefer "refs/remotes/origin/heads/foo" to "refs/remotes/otherremote/tags/foo", or the other way around (or flag the ambiguity and abort). 3. Migration path We need both styles of ref mappings ("traditional", with the implicit and auto-following tag refspec, and "new-style", where all refspecs are explicit) to work side-by-side in the same repo (i.e. having one remote use traditional refspecs, while another uses new-style). At first, we will probably still default to the traditional refspecs when creating a new remote, but over time we should migrate to new-style refspecs, before finally deprecating the traditional refspecs. I'm not sure if traditional vs. new-style can be reliably autodetected from the refspecs themselves, or if we need an explicit per-remote config variable to discern between the two. I think all of the above problems are solvable. ...Johan -- Johan Herland, <johan@xxxxxxxxxxx> www.herland.net -- 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