On 10-11-03 08:49 PM, Johan Herland wrote: > On Wednesday 03 November 2010, Sverre Rabbelier wrote: >> On Wed, Nov 3, 2010 at 17:17, Junio C Hamano <gitster@xxxxxxxxx> wrote: >>> I was actually thinking more along the lines of "not keeping track of >>> remote state at all". We don't do that for tags either. >> >> I would rather see us go the other way (and make the tags refspec put >> tags under refs/tags/remotes/.../). I can understand not scoping tags >> (since they're supposed to be immutable, and are usually global), but >> I don't think the same holds for notes. Notes _are_ versioned, and >> it's expected that users will collaborate. > > Agreed. I don't see how you can easily share and manipulate notes between > repos _without_ keeping the remote state separate from the local state. > > > I'm probably gonna be flamed for this, but I'd like to go even further, and > - for a future major version of Git - reconsider Git's default refspecs. > Currently we have: > > Remote repo -> Local repo > ------------------------------------------------ > refs/heads/* refs/remotes/$remote/* > refs/tags/* refs/tags/* > refs/notes/* ??? > > Of these, the first is specified in the config, the second is > implicit/magic, and the third would be specified in the config. > > I'd probably suggest a more straightforward (and hopefully less confusing) > setup like this: > > Remote repo -> Local repo > ------------------------------------------------ > refs/heads/* refs/remotes/$remote/heads/* > refs/tags/* refs/remotes/$remote/tags/* > refs/notes/* refs/remotes/$remote/notes/* > > ...and these would all be set in the config, i.e. no implicit/magic > refspecs. I'll second this proposal, at least as far as tags go. I can offer two reasons to support this. First, I think the assumption that tags are immutable is too strong. In our repo, we try to keep our topic branches mergeable into both the "master" and "maintenance-of-the-latest-release" branches. This means the topic branches need to be based at the point where the maintenance and master branches diverged. Making this rule easy to follow is best accomplished with a tag, e.g. "topic-base", but that tag will move when we create a new maintenance branch for a new release. With the current tag semantics, when that happens everyone has to delete their local topic-base tags and get the new one from the common/shared repo. People who forget to do this end up basing their topics on outdated code, with predictable results. It would be much easier to be able to just use an "origin/topic-base" tag instead, one that that tracks the topic-base tag in the origin repo. Second, I agree with Johan that the current semantics are confusing. I'm basically the git guru here at work, so it falls to me to teach people how git works and how to use it. I find that once people wrap their minds around the concept of remote and local branches, they get tripped up by the way tags work. IMHO it would be more intuitive if tags used the same local/remote semantics as branches. 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