Re: Keeping unreachable objects in a separate pack instead of loose?

[Ted Ts'o <tytso@mit.edu>]

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