On Saturday, July 10, 2010 03:47:14 pm you wrote: > Joshua Jensen <jjensen@xxxxxxxxxxxxxxxxx> 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 -- 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