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