On 09/26/2013 12:54 AM, Nicolas Pitre wrote: > On Tue, 24 Sep 2013, Jeff King wrote: >> I think most of this problem is the way that we fetch tags straight into >> the refs/tags hierarchy. You would not do: >> >> [remote "origin"] >> fetch = +refs/heads/*:refs/heads/* >> prune = true >> >> unless you wanted to be a pure-mirror, because you would hose your local >> changes any time you fetched. But that is _exactly_ what we do with a >> refs/tags/*:refs/tags/* fetch. >> >> If we instead moved to a default fetch refspec more like: >> >> [remote "origin"] >> fetch = +refs/*:refs/remotes/origin/refs/* >> >> Then everything would Just Work. [...] > > I remember participating to a discussion about this like 2.5 years ago: > > http://news.gmane.org/group/gmane.comp.version-control.git/thread=165799 > > The flat tag namespace remains my major annoyance with git IMHO. I just reviewed that old thread to determine its relevance to the present discussion. For the benefit of the other readers, here is a summary of the main points that I got out of it. The main proposal under discussion was that of Johan Herland: http://article.gmane.org/gmane.comp.version-control.git/165885 Nicolas made the two best arguments for the necessity of separate tag namespaces per remote in *some* form: > The extraordinary misfeature of the tag namespace at the moment > comes from the fact that whenever you add a remote repo to fetch, > and do fetch it, then your flat tag namespace gets polluted with all > the tags the remote might have. If you decide to delete some of > those remote branches, the tags that came with it are still there > and indistinguishable from other tags making it a real pain to sort > out. > > -- http://article.gmane.org/gmane.comp.version-control.git/166108 and > Let's take the OpenOffice vs LibreOffice as an example. What if I > want both in my repository so I can easily perform diffs between > those independent branches? They may certainly end up producing > releases with the same version numbers (same tag name) but different > content (different tag references). > > -- http://article.gmane.org/gmane.comp.version-control.git/166749 Other discussion and open issues regarding a ref namespace reorg: * What exactly would be the ambiguity rules for references with the same name that appear in multiple remotes' namespaces? * Are references to two annotated tags considered the same if they refer to the same SHA-1, even if the annotated tags are different? What about an annotated vs an unannotated tag? The consensus seemed to be "no". * Do they depend on how the reference is being used? Yes, sometimes only a SHA-1 is needed, in which case multiple agreeing references shouldn't be a problem. Other times the DWIM caller needs the full refname (e.g., "git push" pushes to different locations depending on whether the source is a branch or tag), in which case the rules would have to be more nuanced. * Should the same ambiguity rules be applied to other references (e.g., branches)? * What if a branch and a tag have the same name? * Nicolas Pitre suggested that usually they should be accepted if they have the same value, and if the refname matters then the branch should take precedence (with a warning). * Peff pointed out that currently dwim_ref prefers tags, but that Junio has said that that behavior was arbitrary [and by implication could be changed]. He suggested: > For dwim_ref, it prefers the tag and issues a warning. For > git-push, it complains about the ambiguity and dies. For git > checkout, we prefer the head. For git-tag, we prefer the tag > (though I think that only matters for "git tag -d"). > > -- http://article.gmane.org/gmane.comp.version-control.git/166290 * What should "name-rev", "describe", "--decorate" output? See discussion here: http://article.gmane.org/gmane.comp.version-control.git/165911 * "fetch" should probably warn if it ends up fetching a tag with the same name (according to the refname disambiguation rules) but value that conflicts with an existing tag in a different namespace. * Do we need some pathspec modifier (e.g., "~") to specify that the corresponding references should be auto-followed in the manner currently done for refs/tags/*? Or is auto-following maybe not needed at all anymore?: http://article.gmane.org/gmane.comp.version-control.git/160726 Junio thought, and Johan agreed, that tag auto-following should still be done for repositories that use the old ref namespace format. But perhaps this could be special-cased via a config setting rather than built into the refspec syntax. * How would somebody (e.g., an interim maintainer) suck down tags from a project into his own refs/tags/* namespace? (Would it even be necessary?) Should there be a tool for this? [It seems to me that something like git fetch . refs/remotes/origin/tags/*:refs/tags/* would do the trick, as long as pruning were turned off.] * What special handling (if any) is required for refs/remotes/$REMOTE/HEAD? * According to Junio, HEAD is meant to indicate which branch is the "main" branch of the remote. It is not transferred via the protocol, but rather guessed at by the client's "clone" process: http://article.gmane.org/gmane.comp.version-control.git/166694 http://article.gmane.org/gmane.comp.version-control.git/166740 * How would this help somebody who wants to fetch content from multiple projects (e.g., git, gitk, gitgui) into a single repo? There might be tags with the same names but very different meanings, and it would be awkward if there were ambiguity warnings all over the place. [Would it work to configure the fetching repo something like [remote "gitk-origin"] fetch = refs/tags/*:refs/remotes/gitk-origin/tags/gitk/* and to refer to a hypothetical gitk tag "v1.2.3" as "gitk/1.2.3"? Admittedly this is somewhat ambiguous with the proposed DWIM pattern <REMOTE>/<TAGNAME>.] * It might be nice to have a command like git push $REMOTE --interactive that allows the user to choose interactively which branches/tags to push -- http://article.gmane.org/gmane.comp.version-control.git/166700 I hope that saves somebody the time of reading the whole thread (though admittedly my summary is not especially short either). As far as I can tell, the division of tags into remote-specific namespaces would be another way of preventing the problem of tags being pruned too aggressively. But given that such a big change would be a huge development effort, implementing something like the following might be a quicker fix and would not conflict with a hypothetical future ref namespace reorganization: 1. Limit "git fetch --prune" to only pruning references that are under refs/remotes/* 2. Add a new option --prune-tags that removes the above limitation 3. And the above two changes would make this one possible: Change the meaning of the --tags option to mean "fetch all tags *in addition to* (rather than *instead of*) the references that would otherwise be fetched". Comments? @Johan, I know that you were working on the ref-namespace issue at GitMerge. Did your work get anywhere? Are you still working on it? Have you documented somewhere any new insights that you have gained about the problem space? Michael -- Michael Haggerty mhagger@xxxxxxxxxxxx http://softwareswirl.blogspot.com/ -- 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