Re: Archiving tags/branches?

[Pete Harlan <pgit@pcharlan.com>]

David Symonds wrote:
> On Sat, Oct 18, 2008 at 12:43 PM, Pete Harlan <pgit@pcharlan.com>
> wrote:
>> Hi,
>> 
>> I'm looking for a way to manage an ever-growing list of tags.  I've
>> read some git docs, but am new to git and wonder if the below
>> method doesn't work or if there's a standard practice I haven't run
>> into.
>> 
>> Most of the tags in my repo are uninteresting to look at, but can't
>> be deleted.  (Code releases for the most part, or stalled topic
>> branches.) If I wanted to archive those, it looks like this would
>> work:
> 
> Is it really true that they can't be deleted? The only reason to
> avoid it might be for preventing Git's GC from cleaning them up, but
> if all your branches/tags are reachable via "interesting"
> branches/tags then you could just slap the tag name and SHA1 in a
> text file somewhere.
> 
> 
> Dave.

Thank you for your response.  The tags aren't reachable; they're
dead-end branches.

Our development history looks like this:

o---o---o---o---o---o---o---o---o---o---o---o---o---o master
 \                   \                   \
  o---o---o r1.0      o---o---o r1.1      o---o---o r1.2

with releases branched off the development line and stabilized during
QA.  Fixes into the release branches are cherry-picked out of master,
with no merges.

With a new release every few weeks, the tags pile up.

(There are workflows, such as git.git's, where the release tags form one
long line of development, and when we start using git we may use a
different workflow, but the above was our svn workflow, for the
obvious reason that svn doesn't understand merges.  We're going to
import hundreds of such branches in the conversion to git; most such
names are noise, but we don't want to lose the history.)

I would think a built-in feature for archiving refs would be useful to
other projects, even when the tags/branches are reachable and therefore
one could manually stash them in a file.  Getting the design right is
tricky because there are a lot of different ways to approach it, but the
idea seems generally useful to me.

One direction would be to support directory commands for tags, using
refs/tags and refs/branches as the root directories of trees.  (This was
the solution in svn, which naturally supports a hierarchy of branches.)
 Another would be to have a regexp for hiding tags/branches with a
certain pattern (e.g., leading '.').  What I'll probably do in the short
term is write an alias that lists the most recent 10 tags and use that
most of the time.

--Pete