On Tue, Feb 1, 2011 at 11:16 AM, Nicolas Pitre <nico@xxxxxxxxxxx> wrote: > On Tue, 1 Feb 2011, Nguyen Thai Ngoc Duy wrote: >> Another random wish, which does not come with a proposal. How about >> tag namespace (ie. tags from a remote stay in remote namespace)? > > Please make this into a proper proposal. Âthis would be indeed a huge > improvement. OK I'm not familiar with tag code, but I can try. Proposal: Reserve refs/remote-tags namespace to store tags from remotes. Its structure is the same as in refs/remotes. When pulling tags, put them in refs/remote-tags/<remote> instead of refs/tags. Tag dereference code will be taught about refs/remote-tags with similar deref order as in remote branches. Config branch.*.globalTags (perhaps takes a pattern?) may be defined to create refs/tags/* in addition to refs/remote-tags/<remote>/* when fetching tags. Migration plan: refs/remote-tags will be used to store new tags unconditionally, which means there will be duplicates with the already-fetched tags in global namespace. Perhaps we can check if they point to the same sha-1, then choose not to annoy users with ambiguous tag messages? I suggest to add config compatibility.remoteTagNamespace, default to false, which retains current behavior (i.e. also create tags in global namespace in addition to refs/remote-tags). After 1.8.0 (or a few more cycles) the default value becomes true. Users who wish to keep old behavior can put "false" in their ~/.gitconfig. After a few years, remove support for the config key. Unrecognized compatibility.* keys will abort program. Users are forced to new behavior. I don't know, we may want to start annoy users that have the config key set a few cycles before we drop support. -- Duy -- 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