On Mon, Jun 11, 2012 at 01:54:19PM -0400, Jeff King wrote: > > 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. Well, I don't do a simple gc. See the complicated set of steps I use to make sure I don't lose loose commits at the end of my last e-mail message on this thread. It gets worse when I have multiple devel repos, but I simplified things for the purposes of discussion. > 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. So you basically are copying the refs around and making sure the parent repo has an uptodate pointer of all of the child repos, such that when you do the repack, *all* of the commits end up in the parent commit, correct? The system that I'm using means that objects which are local to a child repo stays in the child repo, and if an object is about to be dropped from the parent repo as a result of a gc, the child repo has an opportunity claim a copy of that object for itself in its object database. You can do things either way. I like knowing that objects only used by a child repo are in the child repo's .git directory, but that's arguably more of a question of taste than anything else. - Ted -- 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