{"thread":{"id":"15943","subject":"Archiving tags/branches?","startedAt":"2008-10-18T01:43:46Z","lastAt":"2008-10-21T09:33:48Z","messageCount":14,"participants":["Pete Harlan","David Symonds","SZEDER Gábor","Johan Herland","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"93331","messageId":"48F93F52.4070506@pcharlan.com","threadId":"15943","inReplyTo":null,"subject":"Archiving tags/branches?","fromName":"Pete Harlan","fromEmail":"pgit@pcharlan.com","sentAt":"2008-10-18T01:43:46Z","receivedAt":"2008-10-18T01:43:46Z","isPatch":false,"sender":{"key":"pgit@pcharlan.com","avatar":null},"body":"Hi,\n\nI'm looking for a way to manage an ever-growing list of tags.  I've read\nsome git docs, but am new to git and wonder if the below method doesn't\nwork or if there's a standard practice I haven't run into.\n\nMost of the tags in my repo are uninteresting to look at, but can't be\ndeleted.  (Code releases for the most part, or stalled topic branches.)\n If I wanted to archive those, it looks like this would work:\n\nmkdir .git/refs/archived-tags\ncp -a .git/refs/tags/* .git/refs/archived-tags\ngit tag -d <tag-to-hide> # repeat as necessary\n\nI can then maintain a short list of tags that currently interest me, but\nam guaranteed not to lose old branches (say) referenced by those tags.\n\nIs there a reason this won't work?\n\nThe immediate downsides I see are:\n\n1. The name \"archived-tags\" might clash someday with a git directory.\n\n2. I have to manually copy this to clones if I want it there too, and\ncan't manage it from them remotely.\n\nIn general, I'm thinking flat tag and branch namespaces must get\nunweildy, and short of implementing directory-style namespace management\nwithin git (e.g., hide tags beginning with \".\" by default, allow tag\nsubdirectories) I'm looking for a workaround.\n\nThanks,\n\n--Pete\n"},{"id":"93335","messageId":"ee77f5c20810171950j9ab85bfi6eddca167f86fda2@mail.gmail.com","threadId":"15943","inReplyTo":"48F93F52.4070506@pcharlan.com","subject":"Re: Archiving tags/branches?","fromName":"David Symonds","fromEmail":"dsymonds@gmail.com","sentAt":"2008-10-18T02:50:42Z","receivedAt":"2008-10-18T02:50:42Z","isPatch":false,"sender":{"key":"dsymonds@gmail.com","avatar":"https://gravatar.com/avatar/b22f5051cbfc11836e36cf7a690e6cde4e225d835e13295ff98d15c7a9ee3c0f?d=mp&s=160"},"body":"On Sat, Oct 18, 2008 at 12:43 PM, Pete Harlan <pgit@pcharlan.com> wrote:\n> Hi,\n>\n> I'm looking for a way to manage an ever-growing list of tags.  I've read\n> some git docs, but am new to git and wonder if the below method doesn't\n> work or if there's a standard practice I haven't run into.\n>\n> Most of the tags in my repo are uninteresting to look at, but can't be\n> deleted.  (Code releases for the most part, or stalled topic branches.)\n>  If I wanted to archive those, it looks like this would work:\n\nIs it really true that they can't be deleted? The only reason to avoid\nit might be for preventing Git's GC from cleaning them up, but if all\nyour branches/tags are reachable via \"interesting\" branches/tags then\nyou could just slap the tag name and SHA1 in a text file somewhere.\n\n\nDave.\n"},{"id":"93354","messageId":"20081018102345.GA3749@neumann","threadId":"15943","inReplyTo":"48F93F52.4070506@pcharlan.com","subject":"Re: Archiving tags/branches?","fromName":"SZEDER Gábor","fromEmail":"szeder@ira.uka.de","sentAt":"2008-10-18T10:23:45Z","receivedAt":"2008-10-18T10:23:45Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"Hi Pete,\n\nOn Fri, Oct 17, 2008 at 06:43:46PM -0700, Pete Harlan wrote:\n>  If I wanted to archive those, it looks like this would work:\n> \n> mkdir .git/refs/archived-tags\n> cp -a .git/refs/tags/* .git/refs/archived-tags\n> git tag -d <tag-to-hide> # repeat as necessary\n> \n> I can then maintain a short list of tags that currently interest me, but\n> am guaranteed not to lose old branches (say) referenced by those tags.\n> \n> Is there a reason this won't work?\n\nYes:\n\n$ git --version\ngit version 1.6.0.2.574.g7d0e0\n$ git init\nInitialized empty Git repository in /home/szeder/tmp/git/archive/.git/\n$ echo 1 >foo\n$ git add foo\n$ git commit -m bar\nCreated initial commit 0c92489: bar\n 1 files changed, 1 insertions(+), 0 deletions(-)\n create mode 100644 foo\n$ git tag t\n$ git update-ref refs/archived-tags/t t\n$ git tag -d t\nDeleted tag 't'\n$ cat .git/refs/archived-tags/t\n0c92489da6ec6dfd9875eb590d820fcceb01829b\n$ git gc\nCounting objects: 3, done.\nWriting objects: 100% (3/3), done.\nTotal 3 (delta 0), reused 0 (delta 0)\n$ cat .git/refs/archived-tags/t\ncat: .git/refs/archived-tags/t: No such file or directory\n\nSo, if you put any tags or branches under refs/whatever-non-standard/,\nthen it gets deleted when you gc (or when gc is run automatically).\n\nI don't know whether this behaviour is intentional or not, but I have\nexperienced this the hard way recently.\n\nRegards,\nGábor\n"},{"id":"93355","messageId":"200810181315.49265.johan@herland.net","threadId":"15943","inReplyTo":"20081018102345.GA3749@neumann","subject":"Re: Archiving tags/branches?","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2008-10-18T11:15:49Z","receivedAt":"2008-10-18T11:15:49Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Saturday 18 October 2008, SZEDER Gábor wrote:\n> Hi Pete,\n>\n> On Fri, Oct 17, 2008 at 06:43:46PM -0700, Pete Harlan wrote:\n> >  If I wanted to archive those, it looks like this would work:\n> >\n> > mkdir .git/refs/archived-tags\n> > cp -a .git/refs/tags/* .git/refs/archived-tags\n> > git tag -d <tag-to-hide> # repeat as necessary\n> >\n> > I can then maintain a short list of tags that currently interest me,\n> > but am guaranteed not to lose old branches (say) referenced by those\n> > tags.\n> >\n> > Is there a reason this won't work?\n>\n> Yes:\n>\n> [...]\n>\n> So, if you put any tags or branches under refs/whatever-non-standard/,\n> then it gets deleted when you gc (or when gc is run automatically).\n>\n> I don't know whether this behaviour is intentional or not, but I have\n> experienced this the hard way recently.\n\nGo have a look in .git/packed-refs. Then have a read through \ngit-pack-refs(1).\n\n\nHave fun! :)\n\n...Johan\n\n-- \nJohan Herland, <johan@herland.net>\nwww.herland.net\n"},{"id":"93364","messageId":"20081018130204.GB3749@neumann","threadId":"15943","inReplyTo":"200810181315.49265.johan@herland.net","subject":"Re: Archiving tags/branches?","fromName":"SZEDER Gábor","fromEmail":"szeder@ira.uka.de","sentAt":"2008-10-18T13:02:04Z","receivedAt":"2008-10-18T13:02:04Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Sat, Oct 18, 2008 at 01:15:49PM +0200, Johan Herland wrote:\n> Go have a look in .git/packed-refs. Then have a read through \n> git-pack-refs(1).\nOh, indeed, my good old refs are there!  Thanks for the info.\n\nGábor\n"},{"id":"93365","messageId":"200810181532.59883.johan@herland.net","threadId":"15943","inReplyTo":"20081018130204.GB3749@neumann","subject":"Re: Archiving tags/branches?","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2008-10-18T13:32:59Z","receivedAt":"2008-10-18T13:32:59Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Saturday 18 October 2008, SZEDER Gábor wrote:\n> On Sat, Oct 18, 2008 at 01:15:49PM +0200, Johan Herland wrote:\n> > Go have a look in .git/packed-refs. Then have a read through\n> > git-pack-refs(1).\n>\n> Oh, indeed, my good old refs are there!  Thanks for the info.\n\nBTW, the best way IMHO to archive old refs is to clone your repo (with all \ntags/branches) to a backup disk, and then regularly push (git push --all && \ngit push --tags) your new tags/branches to this backup. You are now free to \ndelete these tags/branches from your work repo (they will not be deleted \nfrom the backup unless you use \"git push --mirror\"). And if you ever need \nto retrieve an old tag/branch, it's just a matter of pulling it from the \nbackup repo. Nice, clean, flexible, and requires no changes to git.\n\n\nHave fun! :)\n\n...Johan\n\n-- \nJohan Herland, <johan@herland.net>\nwww.herland.net\n"},{"id":"93486","messageId":"48FC21C6.90600@pcharlan.com","threadId":"15943","inReplyTo":"ee77f5c20810171950j9ab85bfi6eddca167f86fda2@mail.gmail.com","subject":"Re: Archiving tags/branches?","fromName":"Pete Harlan","fromEmail":"pgit@pcharlan.com","sentAt":"2008-10-20T06:14:30Z","receivedAt":"2008-10-20T06:14:30Z","isPatch":false,"sender":{"key":"pgit@pcharlan.com","avatar":null},"body":"David Symonds wrote:\n> On Sat, Oct 18, 2008 at 12:43 PM, Pete Harlan <pgit@pcharlan.com>\n> wrote:\n>> Hi,\n>> \n>> I'm looking for a way to manage an ever-growing list of tags.  I've\n>> read some git docs, but am new to git and wonder if the below\n>> method doesn't work or if there's a standard practice I haven't run\n>> into.\n>> \n>> Most of the tags in my repo are uninteresting to look at, but can't\n>> be deleted.  (Code releases for the most part, or stalled topic\n>> branches.) If I wanted to archive those, it looks like this would\n>> work:\n> \n> Is it really true that they can't be deleted? The only reason to\n> avoid it might be for preventing Git's GC from cleaning them up, but\n> if all your branches/tags are reachable via \"interesting\"\n> branches/tags then you could just slap the tag name and SHA1 in a\n> text file somewhere.\n> \n> \n> Dave.\n\nThank you for your response.  The tags aren't reachable; they're\ndead-end branches.\n\nOur development history looks like this:\n\no---o---o---o---o---o---o---o---o---o---o---o---o---o master\n \\                   \\                   \\\n  o---o---o r1.0      o---o---o r1.1      o---o---o r1.2\n\nwith releases branched off the development line and stabilized during\nQA.  Fixes into the release branches are cherry-picked out of master,\nwith no merges.\n\nWith a new release every few weeks, the tags pile up.\n\n(There are workflows, such as git.git's, where the release tags form one\nlong line of development, and when we start using git we may use a\ndifferent workflow, but the above was our svn workflow, for the\nobvious reason that svn doesn't understand merges.  We're going to\nimport hundreds of such branches in the conversion to git; most such\nnames are noise, but we don't want to lose the history.)\n\nI would think a built-in feature for archiving refs would be useful to\nother projects, even when the tags/branches are reachable and therefore\none could manually stash them in a file.  Getting the design right is\ntricky because there are a lot of different ways to approach it, but the\nidea seems generally useful to me.\n\nOne direction would be to support directory commands for tags, using\nrefs/tags and refs/branches as the root directories of trees.  (This was\nthe solution in svn, which naturally supports a hierarchy of branches.)\n Another would be to have a regexp for hiding tags/branches with a\ncertain pattern (e.g., leading '.').  What I'll probably do in the short\nterm is write an alias that lists the most recent 10 tags and use that\nmost of the time.\n\n--Pete\n"},{"id":"93485","messageId":"48FC26DA.10508@pcharlan.com","threadId":"15943","inReplyTo":"200810181532.59883.johan@herland.net","subject":"Re: Archiving tags/branches?","fromName":"Pete Harlan","fromEmail":"pgit@pcharlan.com","sentAt":"2008-10-20T06:36:10Z","receivedAt":"2008-10-20T06:36:10Z","isPatch":false,"sender":{"key":"pgit@pcharlan.com","avatar":null},"body":"Johan Herland wrote:\n> BTW, the best way IMHO to archive old refs is to clone your repo (with all \n> tags/branches) to a backup disk, and then regularly push (git push --all && \n> git push --tags) your new tags/branches to this backup. You are now free to \n> delete these tags/branches from your work repo (they will not be deleted \n> from the backup unless you use \"git push --mirror\"). And if you ever need \n> to retrieve an old tag/branch, it's just a matter of pulling it from the \n> backup repo. Nice, clean, flexible, and requires no changes to git.\n> \n> \n> Have fun! :)\n> \n> ...Johan\n\nHi,\n\nThank you; that indeed seems to work and solves the problem of managing\nrefs/archived-tags manually.\n\nUsing a secondary repo solely to overcome a flat tag/branch namespace\nfeels hackish.  Perhaps git will benefit someday from work in this area,\nbut until I come up with a patch your suggestion should work fine.  Just\nknowing I didn't overlook an existing feature helps a lot.\n\n--Pete\n"},{"id":"93497","messageId":"200810200953.45339.johan@herland.net","threadId":"15943","inReplyTo":"48FC26DA.10508@pcharlan.com","subject":"Re: Archiving tags/branches?","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2008-10-20T07:53:45Z","receivedAt":"2008-10-20T07:53:45Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Monday 20 October 2008, Pete Harlan wrote:\n> Johan Herland wrote:\n> > BTW, the best way IMHO to archive old refs is to clone your repo (with\n> > all tags/branches) to a backup disk, and then regularly push (git push\n> > --all && git push --tags) your new tags/branches to this backup. You\n> > are now free to delete these tags/branches from your work repo (they\n> > will not be deleted from the backup unless you use \"git push\n> > --mirror\"). And if you ever need to retrieve an old tag/branch, it's\n> > just a matter of pulling it from the backup repo. Nice, clean,\n> > flexible, and requires no changes to git.\n> >\n> >\n> > Have fun! :)\n> >\n> > ...Johan\n>\n> Hi,\n>\n> Thank you; that indeed seems to work and solves the problem of managing\n> refs/archived-tags manually.\n>\n> Using a secondary repo solely to overcome a flat tag/branch namespace\n> feels hackish.  Perhaps git will benefit someday from work in this area,\n> but until I come up with a patch your suggestion should work fine.  Just\n> knowing I didn't overlook an existing feature helps a lot.\n\n>From reading your other emails, I get the feeling that I'm in a similar \nsituation at $dayjob (i.e. converting ~9 years of development history from \nCVS to Git). We have literally tens of thousands of tags (mostly build and \nrelease tags) in some of our repos, and keeping all these tags in our daily \nwork repos is simply unwieldy and impractical. We therefore plan to have \nofficial reps which only contain the most important tags, and \nhave \"archive\" repos in a different location that contain all the other \ntags.\n\nYou seem to want to keep all your tags in the work repo, but in a \nseparate/hidden namespace, so that they don't clutter the default tag \nlistings. IMHO, once you get into thousands of tags, cloning and other \noperations where all refs are synchronized become annoyingly slow (although \nthings are certainly somewhat better in v1.6). At that point, my only \nadvice is to keep the lesser-used tags in separate repos, and pull each ref \ninto your work repos on-demand, especially when most of these tags will \nprobably never be referenced.\n\n\nHave fun! :)\n\n...Johan\n\n-- \nJohan Herland, <johan@herland.net>\nwww.herland.net\n"},{"id":"93520","messageId":"m3prlvibb7.fsf@localhost.localdomain","threadId":"15943","inReplyTo":"48FC26DA.10508@pcharlan.com","subject":"Re: Archiving tags/branches?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-10-20T14:35:46Z","receivedAt":"2008-10-20T14:35:46Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Pete Harlan <pgit@pcharlan.com> writes:\n\n> Johan Herland wrote:\n\n> > BTW, the best way IMHO to archive old refs is to clone your repo\n> > (with all tags/branches) to a backup disk, and then regularly push\n> > (git push --all && git push --tags) your new tags/branches to this\n> > backup. You are now free to delete these tags/branches from your\n> > work repo (they will not be deleted from the backup unless you use\n> > \"git push --mirror\"). And if you ever need to retrieve an old\n> > tag/branch, it's just a matter of pulling it from the backup\n> > repo. Nice, clean, flexible, and requires no changes to git.\n> \n> Thank you; that indeed seems to work and solves the problem of managing\n> refs/archived-tags manually.\n> \n> Using a secondary repo solely to overcome a flat tag/branch namespace\n> feels hackish.  Perhaps git will benefit someday from work in this area,\n> but until I come up with a patch your suggestion should work fine.  Just\n> knowing I didn't overlook an existing feature helps a lot.\n\nI don't quite understand what you mean by _flat_ namespace for tags\nand branches.\n\nFirst, it is not unusual to have hierarchical branch names, at least\nfor short-term topic branches. For example in git.git history (and in\n\"What's cooking...\" announcements on git mailing list) you can find\nbranch names such as rs/alloc-ref, nd/narrow, tr/workflow-doc.\nAdditionally remote-tracking branch names have inherently hierarchical\nnames: refs/remotes/<remote>/<remote branch>.  While tag names usually\nare of the type x.y.z, it is not mandated by some technological\nlimitation.\n\nSecond, you can always put your archived refs in another namespace,\nbeside 'heads', 'tags', and 'remotes'. I for example use\nrefs/tags/Attic for lightweigth tags to some interesting abandoned\nexperiments, but it could have been refs/deleted/tags, or\nrefs/Attic/tags.\n\nLast, please remember that there exists something like packed refs\nformat (see git-pack-refs(1)... oops, it dies not describe\n.git/packed-refs format, unfortunately).\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"93573","messageId":"48FD4437.1080504@pcharlan.com","threadId":"15943","inReplyTo":"200810200953.45339.johan@herland.net","subject":"Re: Archiving tags/branches?","fromName":"Pete Harlan","fromEmail":"pgit@pcharlan.com","sentAt":"2008-10-21T02:53:43Z","receivedAt":"2008-10-21T02:53:43Z","isPatch":false,"sender":{"key":"pgit@pcharlan.com","avatar":null},"body":"Johan Herland wrote:\n> On Monday 20 October 2008, Pete Harlan wrote:\n>> Johan Herland wrote:\n>>> BTW, the best way IMHO to archive old refs is to clone your repo (with\n>>> all tags/branches) to a backup disk, and then regularly push (git push\n>>> --all && git push --tags) your new tags/branches to this backup. You\n>>> are now free to delete these tags/branches from your work repo (they\n>>> will not be deleted from the backup unless you use \"git push\n>>> --mirror\"). And if you ever need to retrieve an old tag/branch, it's\n>>> just a matter of pulling it from the backup repo. Nice, clean,\n>>> flexible, and requires no changes to git.\n>>>\n>>>\n>>> Have fun! :)\n>>>\n>>> ...Johan\n>> Hi,\n>>\n>> Thank you; that indeed seems to work and solves the problem of managing\n>> refs/archived-tags manually.\n>>\n>> Using a secondary repo solely to overcome a flat tag/branch namespace\n>> feels hackish.  Perhaps git will benefit someday from work in this area,\n>> but until I come up with a patch your suggestion should work fine.  Just\n>> knowing I didn't overlook an existing feature helps a lot.\n> \n> From reading your other emails, I get the feeling that I'm in a similar \n> situation at $dayjob (i.e. converting ~9 years of development history from \n> CVS to Git). We have literally tens of thousands of tags (mostly build and \n> release tags) in some of our repos, and keeping all these tags in our daily \n> work repos is simply unwieldy and impractical. We therefore plan to have \n> official reps which only contain the most important tags, and \n> have \"archive\" repos in a different location that contain all the other \n> tags.\n\nAnother solution that may work for me is to bind the old lines of\ndevelopment together using the merge strategy \"ours\" to link them in a\nchain.  When I first read about \"ours\" I thought it only has evil\napplications, but it seems to be created for just this sort of tying\ntogether development that is actually, but was not historically, linked.\n Making those tags reachable from current heads would allow stashing\nthem in a versioned file somewhere without cluttering up the real\ntags/branches or requiring a separate repo.\n\n> You seem to want to keep all your tags in the work repo, but in a \n> separate/hidden namespace, so that they don't clutter the default tag \n> listings. IMHO, once you get into thousands of tags, cloning and other \n> operations where all refs are synchronized become annoyingly slow (although \n> things are certainly somewhat better in v1.6). At that point, my only \n> advice is to keep the lesser-used tags in separate repos, and pull each ref \n> into your work repos on-demand, especially when most of these tags will \n> probably never be referenced.\n\nThe efficiency issue is one I hadn't considered; thanks.\n\n--Pete\n"},{"id":"93574","messageId":"48FD55BF.1020207@pcharlan.com","threadId":"15943","inReplyTo":"m3prlvibb7.fsf@localhost.localdomain","subject":"Re: Archiving tags/branches?","fromName":"Pete Harlan","fromEmail":"pgit@pcharlan.com","sentAt":"2008-10-21T04:08:31Z","receivedAt":"2008-10-21T04:08:31Z","isPatch":false,"sender":{"key":"pgit@pcharlan.com","avatar":null},"body":"Jakub Narebski wrote:\n> Pete Harlan <pgit@pcharlan.com> writes:\n> \n>> Johan Herland wrote:\n> \n>>> BTW, the best way IMHO to archive old refs is to clone your repo\n>>> (with all tags/branches) to a backup disk, and then regularly push\n>>> (git push --all && git push --tags) your new tags/branches to this\n>>> backup. You are now free to delete these tags/branches from your\n>>> work repo (they will not be deleted from the backup unless you use\n>>> \"git push --mirror\"). And if you ever need to retrieve an old\n>>> tag/branch, it's just a matter of pulling it from the backup\n>>> repo. Nice, clean, flexible, and requires no changes to git.\n>> Thank you; that indeed seems to work and solves the problem of managing\n>> refs/archived-tags manually.\n>>\n>> Using a secondary repo solely to overcome a flat tag/branch namespace\n>> feels hackish.  Perhaps git will benefit someday from work in this area,\n>> but until I come up with a patch your suggestion should work fine.  Just\n>> knowing I didn't overlook an existing feature helps a lot.\n> \n> I don't quite understand what you mean by _flat_ namespace for tags\n> and branches.\n> \n> First, it is not unusual to have hierarchical branch names, at least\n> for short-term topic branches. For example in git.git history (and in\n> \"What's cooking...\" announcements on git mailing list) you can find\n> branch names such as rs/alloc-ref, nd/narrow, tr/workflow-doc.\n> Additionally remote-tracking branch names have inherently hierarchical\n> names: refs/remotes/<remote>/<remote branch>.  While tag names usually\n> are of the type x.y.z, it is not mandated by some technological\n> limitation.\n\nWhat I mean by \"flat\" is that \"/\" is just another character as far as\nwhat git exposes to the user.  Regardless of any semantics the user\nchooses to assign to it, and regardless of what advantage git makes use\nof \"/\" internally, unless I can do something like:\n\n% git tag --ls\nsometag\nsomeothertag\nreleases/\n% git tag --ls releases/\nreleases/2008/\nreleases/2007/\n% git tag --ls releases/2008\nreleases/2008/r3.14\n%\n\n\"/\" is just like any another character in a tag or branch.\n\n(The above notional --ls modifier is probably very easy to write, and if\nI do so it may address all of my woes.  Subversion's branching/tagging\ncan be organized pretty much exactly like this, and importing into git\nsuch a repository is what initially led me to ask about organizing tags\nand branches.)\n\nWhat I'm usually likely to want from a \"list tags\" command is to see the\nmost recent few tags, not (say) all 226 tags in git.git.  I'll probably\nwrite a little alias that does that, but even then when looking at the\nwhole list it would be nice to have the option to navigate it\nhierarchically.  (Or in some other manner, and/or possibly with a\nconfigurable directory separator.)\n\n> Second, you can always put your archived refs in another namespace,\n> beside 'heads', 'tags', and 'remotes'. I for example use\n> refs/tags/Attic for lightweigth tags to some interesting abandoned\n> experiments, but it could have been refs/deleted/tags, or\n> refs/Attic/tags.\n\nMy original question was asking whether this sort of thing would work\n(e.g., they would never be automatically pruned), and I'm happy to see\nthat the answer is yes.  The main downside to it is that you can't\nclone/pull/push changes to it using git.\n\nMany thanks to you and everyone for their help.  Git is so flexible that\nit can be difficult when starting out to know whether you're missing a\nway of attacking a problem.\n\n--Pete\n\n> Last, please remember that there exists something like packed refs\n> format (see git-pack-refs(1)... oops, it dies not describe\n> .git/packed-refs format, unfortunately).\n"},{"id":"93583","messageId":"200810211015.27257.jnareb@gmail.com","threadId":"15943","inReplyTo":"48FD55BF.1020207@pcharlan.com","subject":"Re: Archiving tags/branches?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-10-21T08:15:26Z","receivedAt":"2008-10-21T08:15:26Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Tue, 21 Oct 2008 06:08, Pete Harlan napisał:\n> Jakub Narebski wrote:\n>> Pete Harlan <pgit@pcharlan.com> writes:\n>>> Johan Herland wrote:\n \n>>>\n>>> Using a secondary repo solely to overcome a flat tag/branch namespace\n>>> feels hackish.  Perhaps git will benefit someday from work in this area,\n>>> but until I come up with a patch your suggestion should work fine.  Just\n>>> knowing I didn't overlook an existing feature helps a lot.\n>> \n>> I don't quite understand what you mean by _flat_ namespace for tags\n>> and branches.\n>> \n>> First, it is not unusual to have hierarchical branch names, at least\n>> for short-term topic branches. For example in git.git history (and in\n>> \"What's cooking...\" announcements on git mailing list) you can find\n>> branch names such as rs/alloc-ref, nd/narrow, tr/workflow-doc.\n>> Additionally remote-tracking branch names have inherently hierarchical\n>> names: refs/remotes/<remote>/<remote branch>.  While tag names usually\n>> are of the type x.y.z, it is not mandated by some technological\n>> limitation.\n> \n> What I mean by \"flat\" is that \"/\" is just another character as far as\n> what git exposes to the user.  Regardless of any semantics the user\n> chooses to assign to it, and regardless of what advantage git makes use\n> of \"/\" internally, unless I can do something like:\n> \n> % git tag --ls\n> sometag\n> someothertag\n> releases/\n> % git tag --ls releases/\n> releases/2008/\n> releases/2007/\n> % git tag --ls releases/2008\n> releases/2008/r3.14\n> %\n\nActually you can have kind of second and third examples; \"git tag -l\"\ntakes optional <pattern> argument, so you can do the folowing without\nany new features:\n\n  # git tag -l 'releases/2008/*'\n  releases/2008/r3.14\n \n(the quotes are to protect wildcard characters against expansion by\nshell)\n\n> \"/\" is just like any another character in a tag or branch.\n> \n> (The above notional --ls modifier is probably very easy to write, and if\n> I do so it may address all of my woes.  Subversion's branching/tagging\n> can be organized pretty much exactly like this, and importing into git\n> such a repository is what initially led me to ask about organizing tags\n> and branches.)\n\nHmmm... it looks like what you are complaining is not the fact that\ntags have flat namespace, but the fact that recursive mode is the\ndefault behavior (something like \"ls -R\" or \"git ls-tree -r\").\n \n> What I'm usually likely to want from a \"list tags\" command is to see the\n> most recent few tags, not (say) all 226 tags in git.git.  I'll probably\n> write a little alias that does that, but even then when looking at the\n> whole list it would be nice to have the option to navigate it\n> hierarchically.  (Or in some other manner, and/or possibly with a\n> configurable directory separator.)\n\nSo you would want some '--local' / '--non-recursive' option to listing\nall tags (for git-tag) and branches (for git-branch).\n\nAs to the \"most recent few tags\":\n  $ git for-each-ref --format='%(refname)' --sort=-taggerdate --count=10 refs/tags/\n\n-- \nJakub Narebski\nPoland\n"},{"id":"93584","messageId":"48FDA1FC.2030206@pcharlan.com","threadId":"15943","inReplyTo":"200810211015.27257.jnareb@gmail.com","subject":"Re: Archiving tags/branches?","fromName":"Pete Harlan","fromEmail":"pgit@pcharlan.com","sentAt":"2008-10-21T09:33:48Z","receivedAt":"2008-10-21T09:33:48Z","isPatch":false,"sender":{"key":"pgit@pcharlan.com","avatar":null},"body":"Jakub Narebski wrote:\n> > (The above notional --ls modifier is probably very easy to write, and if\n> > I do so it may address all of my woes.  Subversion's branching/tagging\n> > can be organized pretty much exactly like this, and importing into git\n> > such a repository is what initially led me to ask about organizing tags\n> > and branches.)\n>\n> Hmmm... it looks like what you are complaining is not the fact that\n> tags have flat namespace, but the fact that recursive mode is the\n> default behavior (something like \"ls -R\" or \"git ls-tree -r\").\n>   \n\nYes, though I hope it didn't sound like I was complaining, just trying \nto understand how people manage these things.  (And \"recursive\" mode\nbeing the only mode is precisely what flattens the namespace.)\n\n\n> > What I'm usually likely to want from a \"list tags\" command is to see the\n> > most recent few tags, not (say) all 226 tags in git.git.  I'll probably\n> > write a little alias that does that, but even then when looking at the\n> > whole list it would be nice to have the option to navigate it\n> > hierarchically.  (Or in some other manner, and/or possibly with a\n> > configurable directory separator.)\n>\n> So you would want some '--local' / '--non-recursive' option to listing\n> all tags (for git-tag) and branches (for git-branch).\n>\n>   \nSure, though I hadn't thought of it in those terms.\n\n> As to the \"most recent few tags\":\n>   $ git for-each-ref --format='%(refname)' --sort=-taggerdate --count=10 refs/tags/\n>\n>   \n\nWell that's pretty slick, thanks :)  I have aliased that to \"lt\", and\n\"lb\" to:\n\nfor-each-ref --format='%(refname:short)'  --sort=-authordate --count=8\nrefs/heads/\n\n(which seems less useful, but it was useful as homework...)\n\nThanks again,\n\n--Pete\n"}]}