On Tue, Feb 1, 2011 at 9:54 PM, Marc Branchaud <marcnarc@xxxxxxxxxxx> wrote: > 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: Thanks. I wrote another proposal (should we have more or less standard "Git Enhancement Proposal" process like Python's PEP or Scheme's SRFI to keep track of these over time?) but it's good to see others look at it too. > 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 One problem with the proposed ref layout is that it breaks current layout (remotes/<remote>/head -> remotes/<remote>/heads/head). Some sort of migration support is needed. On the other hand, new layout is cleaner than my proposal (remote-tags/<remote>/tag). > 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). > ... > 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. Hmm I thought "a-ref" would check "refs/tags/a-ref" and "refs/remotes/*/a-ref". But you are right. Maybe "tags.relative" can take three values instead of boolean (names TBD): - deprecated (current behavior) - migrating (fetch tags to refs/remotes, but tag lookup will look in refs/tags as well as refs/remotes/*/tags) - migrated (fetch tags to refs/remotes, look up in order) We may slowly turn default value step by step until it becomes "migrated". -- 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