Re: Archiving tags/branches?

[Jakub Narebski <jnareb@gmail.com>]

On Tue, 21 Oct 2008 06:08, Pete Harlan napisał:
> Jakub Narebski wrote:
>> Pete Harlan <pgit@pcharlan.com> writes:
>>> Johan Herland wrote:
 
>>>
>>> Using a secondary repo solely to overcome a flat tag/branch namespace
>>> feels hackish.  Perhaps git will benefit someday from work in this area,
>>> but until I come up with a patch your suggestion should work fine.  Just
>>> knowing I didn't overlook an existing feature helps a lot.
>> 
>> I don't quite understand what you mean by _flat_ namespace for tags
>> and branches.
>> 
>> First, it is not unusual to have hierarchical branch names, at least
>> for short-term topic branches. For example in git.git history (and in
>> "What's cooking..." announcements on git mailing list) you can find
>> branch names such as rs/alloc-ref, nd/narrow, tr/workflow-doc.
>> Additionally remote-tracking branch names have inherently hierarchical
>> names: refs/remotes/<remote>/<remote branch>.  While tag names usually
>> are of the type x.y.z, it is not mandated by some technological
>> limitation.
> 
> What I mean by "flat" is that "/" is just another character as far as
> what git exposes to the user.  Regardless of any semantics the user
> chooses to assign to it, and regardless of what advantage git makes use
> of "/" internally, unless I can do something like:
> 
> % git tag --ls
> sometag
> someothertag
> releases/
> % git tag --ls releases/
> releases/2008/
> releases/2007/
> % git tag --ls releases/2008
> releases/2008/r3.14
> %

Actually you can have kind of second and third examples; "git tag -l"
takes optional <pattern> argument, so you can do the folowing without
any new features:

  # git tag -l 'releases/2008/*'
  releases/2008/r3.14
 
(the quotes are to protect wildcard characters against expansion by
shell)

> "/" is just like any another character in a tag or branch.
> 
> (The above notional --ls modifier is probably very easy to write, and if
> I do so it may address all of my woes.  Subversion's branching/tagging
> can be organized pretty much exactly like this, and importing into git
> such a repository is what initially led me to ask about organizing tags
> and branches.)

Hmmm... it looks like what you are complaining is not the fact that
tags have flat namespace, but the fact that recursive mode is the
default behavior (something like "ls -R" or "git ls-tree -r").
 
> What I'm usually likely to want from a "list tags" command is to see the
> most recent few tags, not (say) all 226 tags in git.git.  I'll probably
> write a little alias that does that, but even then when looking at the
> whole list it would be nice to have the option to navigate it
> hierarchically.  (Or in some other manner, and/or possibly with a
> configurable directory separator.)

So you would want some '--local' / '--non-recursive' option to listing
all tags (for git-tag) and branches (for git-branch).

As to the "most recent few tags":
  $ git for-each-ref --format='%(refname)' --sort=-taggerdate --count=10 refs/tags/

-- 
Jakub Narebski
Poland