Johannes Schindelin [off-list ref] writes:
Hi,
On Sat, 10 May 2008, Jeremy Maitin-Shepard wrote:
quoted
Jeff King [off-list ref] writes:
quoted
On Fri, May 09, 2008 at 09:51:15PM -0400, Jeremy Maitin-Shepard wrote:
quoted
quoted
quoted
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.
quoted
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.
quoted
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
Hi,
On Sat, 10 May 2008, Jeremy Maitin-Shepard wrote:
Johannes Schindelin [off-list ref] writes:
quoted
On Sat, 10 May 2008, Jeremy Maitin-Shepard wrote:
quoted
quoted
Jeff King [off-list ref] writes:
quoted
On Fri, May 09, 2008 at 09:51:15PM -0400, Jeremy Maitin-Shepard
wrote:
quoted
quoted
quoted
quoted
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.
quoted
That assumes you _can_ write to the original repository. That may
or may not be the case, depending on your setup.
quoted
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...
quoted
quoted
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.
quoted
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
Johannes Schindelin [off-list ref] writes:
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).
I very strongly agree with you that the suid helper would be the last
ditch thing we would want to avoid doing unless there is no other way. I
also agree with you that the owners of the repository need to be talking.
But I think the tool _could_ help them do their talking. It is
conceivable that just like you can explicitly allow selected others to
push into your own repository, you would want to explicitly allow some
others to ask you to keep objects their repositories borrow from you.
Originally, I wrote "allow others to borrow from you", but that is
very ill defined. If they can read from your repository they can
unilaterally borrow from you without having any write permission
to your repository that is needed to install backpointers.
I am not fundamentally opposed to a backpointer that point at borrowers so
that the lender can protect the objects that are pointed by them.
However, there are two technical issues in the solution of pointing at the
borrower's .git/refs with a symlink from the repository that is borrowed
from, as I pointed out when this came up last time.
- There are systems without symbolic links.
- A symref (e.g. refs/remotes/origin/HEAD of borrower that points at
refs/remotes/origin/master of borrower) is relative to borrower's
repository.