From: Johan Herland <johan@herland.net>
To: git@vger.kernel.org
Cc: "Pete Harlan" <pgit@pcharlan.com>, "SZEDER Gábor" <szeder@ira.uka.de>
Subject: Re: Archiving tags/branches?
Date: Mon, 20 Oct 2008 09:53:45 +0200 [thread overview]
Message-ID: <200810200953.45339.johan@herland.net> (raw)
In-Reply-To: <48FC26DA.10508@pcharlan.com>
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.
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.
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
next prev parent reply other threads:[~2008-10-20 7:55 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-18 1:43 Archiving tags/branches? Pete Harlan
2008-10-18 2:50 ` David Symonds
2008-10-20 6:14 ` Pete Harlan
2008-10-18 10:23 ` SZEDER Gábor
2008-10-18 11:15 ` Johan Herland
2008-10-18 13:02 ` SZEDER Gábor
2008-10-18 13:32 ` Johan Herland
2008-10-20 6:36 ` Pete Harlan
2008-10-20 7:53 ` Johan Herland [this message]
2008-10-21 2:53 ` Pete Harlan
2008-10-20 14:35 ` Jakub Narebski
2008-10-21 4:08 ` Pete Harlan
2008-10-21 8:15 ` Jakub Narebski
2008-10-21 9:33 ` Pete Harlan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200810200953.45339.johan@herland.net \
--to=johan@herland.net \
--cc=git@vger.kernel.org \
--cc=pgit@pcharlan.com \
--cc=szeder@ira.uka.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).