On Tue, Aug 28, 2007 at 12:10:59AM -0400, Shawn O. Pearce wrote:
quoted text
> Its what happens when you use `git clone --shared A B` and the
> repository A that you borrow from removes objects that B depends
> upon.  That is exactly what repo.or.cz is doing, and it is exactly
> what I'm doing at day-job with some large repositories.
> 
> You more or less cannot repack A without making sure it takes B's
> refs into account when it generates the new packfile.
> ...
> Ain't easy, is it?  That --shared flag to git-clone is playing
> with fire.  If you don't want to get burnt, don't use it.  Maybe
> we should rename it --light-a-match-and-burn-me-please.  ;-)

This has been discussed before, and it wouldn't be *that* hard to have
"git clone --shared" create a backpointer from B to A, so that
"git-prune" could also search the B's refs and not prune anything that
is in A which is reachable from heads in A and B.

quoted text
> At day-job I have a hard rule that you cannot even push into an A,
> let alone rewind a branch in it or delete a branch from it.  All of
> my A's that my B's fork from a strictly read-only and are managed
> by me and me alone.  I know what I'm doing...  I think.... ;-)

Why don't you even allow people to push into A?  That should be
safe....

quoted text
> So it really comes down to a rule like the following:
> 
>   If A must be repacked then:
>     1) Hardlink all loose objects/packs from A to all B;
>     2) `git --git-dir=A repack -a -d`
>     3) `git --git-dir=B repack -a -d -l`
>     4) `git --git-dir=B prune`

This is morally the same, but it makes the hardlink step easier (only
one pack to link from A to B), and by using git-gc mit makes it
conceptually easier for people to understand what's going on.

git --git-dir=A gc
ln A/.git/objects/pack/* B/.git/objects
git --git-dir=B gc --prune
git --git-dir=A prune

... and I don't think this is all that scary at all.  :-)

					- Ted
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html