Hi, On Tue, 28 Aug 2007, Theodore Tso wrote: > 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. It _is_ hard, if you want to keep any kind of safe permissions. Think repo.or.cz, forks. > > 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.... Nope: for b in $(git ls-remote /that/other/repo | sed "s/^[^ ]* //") do git push /that/other/repo :$b done Ciao, Dscho - 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
