Re: git gc & deleted branches
- From
- Jeremy Maitin-Shepard <jbms@cmu.edu>
- Date
- May 10, 2008, 16:24 UTC
- Message-ID
- <87prruxh3z.fsf@jeremyms.com>
- In-Reply-To
- <alpine.DEB.1.00.0805101003350.30431@racer>
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:
Show 7 quoted lines
>> >> 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.
Show 6 quoted lines
>> 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