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:
> 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:
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
> -- http://article.gmane.org/gmane.comp.version-control.git/166108
> 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
* 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
* "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?:
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
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
* 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:
* 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
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
* It might be nice to have a command like
git push $REMOTE --interactive
that allows the user to choose interactively which branches/tags to
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
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
@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?
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html