Re: git gc & deleted branches

[Jeremy Maitin-Shepard <jbms@cmu.edu>]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Hi,
> On Sat, 10 May 2008, Jeremy Maitin-Shepard wrote:

>> Jeff King <peff@peff.net> writes:
>> 
>> > On Fri, May 09, 2008 at 09:51:15PM -0400, Jeremy Maitin-Shepard wrote:

>> >> When you create a new working directory, you would also create in the
>> >> original repository a symlink named
>> >> e.g. orig_repo/.git/peers/<some-arbitrary-name-that-doesn't-matter> that
>> >> points to the .git directory of the newly created working directory.
>> 
>> > That assumes you _can_ write to the original repository. That may or may
>> > not be the case, depending on your setup.

> FWIW this argument can be found in the mailing list.  It does not have to 
> be told over and over again, right?

Maybe you can point me at the relevant thread.  Fundamentally, though,
I'd say objects/info/alternates _cannot_ work reliably without the
source repository knowing about the objects that the sharing
repositories need.  Otherwise, there is no way for it to know not to
prune them.  The only way for it to have that information in general is
to write it in the repository.  In a site-specific setting, it may
indeed be possible to rely on some site-specific database, but that is
not particularly relevant.

Currently repository sharing seems to be used in many cases in quite
unsafe ways.  It may seem unfortunate that doing things the "safe way"
is much more of a hassle and doesn't work in certain environments, but
I'd say that is just the way things have to be.

Perhaps you can point me to an existing thread that addresses this idea,
though.

>> Well, I suppose in that case it could print a warning or maybe fail 
>> without some "force" option.  If you can't write to the repository, then 
>> I think it is safe to say that it will never know or care about you, so 
>> you will fundamentally have a fragile setup.  I'd say that except in 
>> very special circumstances, you are better off just not sharing it at 
>> all.

> Counterexample kernel.org.  Counterexample repo.or.cz.

repo.or.cz is not a counterexample.  It is completely "managed", and
could quite easily implement the approach I described.  I don't know
exactly how kernel.org works, but I imagine likewise some setuid helper
script could be provided to write these symlinks.

There is the issue that these setuid helper scripts would mean at the
very least that if user A can "fork" user B's repository, then to some
extent user B can make user A use large amounts of disk space
(i.e. exceed his quota or something) by just referencing a bunch of
temporary objects that user A happens to have in his repository, and it
would take careful examination of the git repository to actually figure
out that it is user B's fault.  I don't think this would be a
significant problem in practice, though.

-- 
Jeremy Maitin-Shepard