Hi, On Sat, 10 May 2008, Jeremy Maitin-Shepard wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > On Sat, 10 May 2008, Jeremy Maitin-Shepard wrote: > > >> Jeff King <peff@xxxxxxxx> 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. Unfortunately, a quick search did not turn up anything useful. Maybe you try your luck yourself... > >> 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. Half true... you said "if you can't write to the repository..." and on repo.or.cz, the first part is true, the second part not. > 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. Well, I think that the setuid helper script would open a whole bunch of other issues. I think that the shared repository problem is rather a semantic one, i.e. it is only solvable between the owners of the repository by good-ole talking, not something that can be solved by the tool (Git). 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
