On Tue, Aug 28, 2007 at 12:10:59AM -0400, Shawn O. Pearce wrote: > 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. > 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.... > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
