Johan Herland <johan@xxxxxxxxxxx> writes: > - Remote tags are now stored separate from local tags. When looking up a > shorthand tag name (e.g. v1.7.4), we should consult local tags > (refs/tags/v1.7.4) before remote tags (refs/remotes/*/tags/v1.7.4 [1]). See > [2] for more details. > - Remote heads have moved into refs/remotes/$remote/heads/*, hence > invalidating shorthand remote head names, like "origin/master". We should > change the lookup code, so that a shorthand ref of the form "$remote/$head" > where "$remote" happens to match a configured remote is eventually expanded > into lookup for "refs/remotes/$remote/heads/$head" [3]. Keeping 'origin/next' usable is a _must_, _if_ we were to go this route. > - We might want to generalize the handling of "$remote/$head" into allowing > shorthands like "$remote/$tag", "$remote/$replace" and "$remote/$note" as > well (provided, of course, that they match unambiguously). > > - All fetch refspecs should be given explicitly. What do you mean by this? > Sub-proposal: While we are changing the default refspecs, we should also > consider whether we want to keep the auto-following behavior that Git > currently does for tags (don't fetch tags that refer to objects not > otherwise fetched by another refspec). If we simply make an explicit > "+refs/tags/*:refs/remotes/$remote/tags/*" refspec, we will lose the auto- > following behavior. If we do want to keep the auto-following behavior, we > could for example add a "~" prefix to the refspec to trigger auto-following > behavior (i.e. this refspec only applies to refs that happen to point at > objects fetched by way of a different refspec). See > http://thread.gmane.org/gmane.comp.version-control.git/160503/focus=160795 > for more details. You seem to envision "auto-follow" to slurp remote tags in remotes/origin/$tag namespace. What should "git fetch --tags $from_there" do? For some reason, many people seem to be enthused about splitting the tag namespace, but I am not sure if that is a good thing in general. Branches are moving pointers for people to flip around in their local repositories, and it makes sense to say "My master is a bit ahead of the public one", but what would we gain by making it _easier_ to add and exchange many tags with the same name (e.g. refs/remotes/*/tags/v1.7.4 vs refs/tags/v1.7.4), other than the extra confusion? While you are talking about drastic reorganization (and rewriting the ref code to support it), another possible Sub-proposal we may want to consider is to allow "next" and "next/foo" at the same time. -- 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