On Mon, Jun 11, 2012 at 01:45:07PM -0400, Ted Ts'o wrote: > There's another useful part of the two week window, and it's as a > partial workaround using .git/objects/info/alternates with one or more > rewinding branches. > > My /usr/projects/e2fsprogs/base repo is a bare repo that contains all > of my public branches, including a rewinding "pu" branch. > > My /usr/projects/e2fsprogs/e2fsprogs uses an alternates file to > minimize disk usage, and it points at the base repo. > > The problem comes when I need to gc the base repo, every 3 months or > so. When I do that, objects that belonged to older incarnations of > the rewinding pu branch disappear. The two week window gives you a > partial saving throw until development repo breaks due to objects that > it depends upon disappearing. You're doing it wrong (but you can hardly be blamed, because there isn't good tool support for doing it right). You should never prune or repack in the base repo without taking into account all of the refs of its children. We have a similar setup at github (every time you "fork" a repo, it is creating a new repo that links back to a project-wide "network" repo for its object store). We maintain a refs/remotes/XXX directory for each child repo, which stores the complete refs/ hierarchy of that child. It's all done by a tangled mass of shell scripts. I've considered trying to clean up and open source them, but I really doubt it would help people generally. There's so much stuff specific to our setup. -Peff -- 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