On 11-01-31 10:20 PM, Nguyen Thai Ngoc Duy wrote: > On Tue, Feb 1, 2011 at 12:05 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Now the 1.7.4 release is out, I'd like people to help thinking about the >> next cycle(s). >> >> As a discussion-starter, here are my random wishes. Even though this does >> not attempt to be exhaustive, keeping the number of goals manageably small >> may help us focus. > > Another random wish, which does not come with a proposal. How about > tag namespace (ie. tags from a remote stay in remote namespace)? I had just started writing up such a proposal yesterday. What I have so far is pretty preliminary: Proposal: Change tag refspecs to distinguish between remote and local tags. An unadorned tag "foo" could point to different commits in different repositories. A remote could move/edit it's "foo" tag and have that update smoothly propagated to clones. I believe this was last brought up in November while discussing the refs base for notes: http://thread.gmane.org/gmane.comp.version-control.git/160503/focus=160655 Risks: I think the main risk lies in breaking plain <tagname> refs, as they would become "origin/<tagname>" refs instead. But I think that can be mitagated against (see below). The other risk folks might raise, though I disagree, is breaking the immutability assumption for tags. I'm willing to debate this, though (see the above-linked thread). Another "risk" is that this change might be too much of an earthquake. It may be something more suitable to a major release, like 2.0. Migration plan: Add a "tags.relative" (name TBD) configuration variable which defaults to false. When tags.relative is true, "git fetch" puts any received tags under (location TBD) refs/remotes/<remote>/tags/. In 1.8.0 we flip tags.realtive's default value. To help mitigate the risk of breaking plain "<tagname>" refs, "git rev-parse" can look for plain names (i.e. ones without a /) in the remote tags location. M. -- 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