Re: Cutting history

From: Jakub Narebski <jnareb@gmail.com>
Date: Jul 10, 2010, 08:47 UTC
Message-ID: <m3tyo7lo6n.fsf@localhost.localdomain>
In-Reply-To: <4C37F24E.30407@workspacewhiz.com>

Joshua Jensen <jjensen@workspacewhiz.com> writes:

Show 8 quoted lines

>   ----- 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...

Show 13 quoted lines

> >
> > 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

-- 
Jakub Narebski
Poland
ShadeHawk on #git