From: Martin Pettersson <martin@siamect.com>
Date: Sat, 10 Jul 2010 10:40:20 GMT
Subject: Re: Cutting history
Message-ID: <201007101740.20854.martin@siamect.com>
In-Reply-To: <m3tyo7lo6n.fsf@localhost.localdomain>

On Saturday, July 10, 2010 03:47:14 pm you wrote:
> Joshua Jensen <jjensen@workspacewhiz.com> writes:
> >   ----- Original Message -----
> > 
> > From: Enrico Weigelt
> > Date: 7/9/2010 9:25 PM
> > 
> > > I'm using git for automatic backups (eg. database dumps). This
> > > works quite well, but as time goes, the history (and so the repo)
> > > gets larger and larger. It would be really nice to allow cutting
> > > off old stuff (eg. after N commits in the past).
> 
> This is certainly Using Git For What It Was Not Intended...
> 
> > > Maybe that could be done by introducing "stopper" tags: commits
> > > that have an stopper-tag may have missing parents, and git-gc
> > > can be told to ignore those parents and throw away everything
> > > behind the stopper (if not referenced otherwise).
> > > 
> > > A probably cleaner, but more invasive way could be making refs
> > > to vectors, which may contain stop points (multiple ones in case
> > > of merges) additionally to the start point. Remote transmits only
> > > contain the commits within this range, and GC also just scans
> > > the range (instead of following all parents).
> > 
> > Your post reminded me of this: http://progit.org/2010/03/17/replace.html
> 
> Another solution would be to make history shallower like shallow clone
> ("git clone --depth <depth>") does it[1], and then prune history.  Or
> you can use grafts to cauterize history.
> 
> Both of those solutions have disadvantages wrt pushing and pulling to
> other repositories (shallow clone less so), but I don't think that
> would be a problem for your situation.
> 
> [1] Documentation/technical/shallow.txt

Don't complicate things, just make new repo when the old one is too large. 
That is what I do and it is for me the best backup system I ever had.
Martin