Hi,

On Tue, 28 Aug 2007, Theodore Tso wrote:

quoted text
> 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.

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....

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html