Re: Local tag killer

[Michael Haggerty <mhagger@alum.mit.edu>]

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@alum.mit.edu
http://softwareswirl.blogspot.com/