Johan Herland wrote: > On Monday 20 October 2008, Pete Harlan wrote: >> Johan Herland wrote: >>> BTW, the best way IMHO to archive old refs is to clone your repo (with >>> all tags/branches) to a backup disk, and then regularly push (git push >>> --all && git push --tags) your new tags/branches to this backup. You >>> are now free to delete these tags/branches from your work repo (they >>> will not be deleted from the backup unless you use "git push >>> --mirror"). And if you ever need to retrieve an old tag/branch, it's >>> just a matter of pulling it from the backup repo. Nice, clean, >>> flexible, and requires no changes to git. >>> >>> >>> Have fun! :) >>> >>> ...Johan >> Hi, >> >> Thank you; that indeed seems to work and solves the problem of managing >> refs/archived-tags manually. >> >> 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. > > From reading your other emails, I get the feeling that I'm in a similar > situation at $dayjob (i.e. converting ~9 years of development history from > CVS to Git). We have literally tens of thousands of tags (mostly build and > release tags) in some of our repos, and keeping all these tags in our daily > work repos is simply unwieldy and impractical. We therefore plan to have > official reps which only contain the most important tags, and > have "archive" repos in a different location that contain all the other > tags. Another solution that may work for me is to bind the old lines of development together using the merge strategy "ours" to link them in a chain. When I first read about "ours" I thought it only has evil applications, but it seems to be created for just this sort of tying together development that is actually, but was not historically, linked. Making those tags reachable from current heads would allow stashing them in a versioned file somewhere without cluttering up the real tags/branches or requiring a separate repo. > You seem to want to keep all your tags in the work repo, but in a > separate/hidden namespace, so that they don't clutter the default tag > listings. IMHO, once you get into thousands of tags, cloning and other > operations where all refs are synchronized become annoyingly slow (although > things are certainly somewhat better in v1.6). At that point, my only > advice is to keep the lesser-used tags in separate repos, and pull each ref > into your work repos on-demand, especially when most of these tags will > probably never be referenced. The efficiency issue is one I hadn't considered; thanks. --Pete -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
