Re: [PATCH 5/6] Teach "fsck" not to follow subproject links

On Wed, 11 Apr 2007, David Lang wrote:

On Wed, 11 Apr 2007, Linus Torvalds wrote:

quoted

It can be a nice space optimization, and yes, if there really is a lot of
shared state, it can make it much cheaper to do some of the checks, but
right now we have absolutely *no* way for fsck to then do the reachability
check, because there is no way to tell fsck where all the refs are (since
now the refs come in from multiple repositories!)

this is why I was suggesting a --multiple-project option to let you tell fsck
about all of the repositories that it needs to look for refs in.

Well, just from a personal observation:
 - I would *personally* actually refuse to share objects with anybody 
   else.

I just find the idea too scary. Somebody doing something bad to their 
object store by mistake (running "git prune" without realizing that there 
are *my* objects there too, or just deciding that they want to play with 
the object directory by hand, or running a new fancy experimental importer 
that has a subtle bug wrt object handling or anything like that).

I'll endorse use "alternates" files, but partly because I know the main 
project is safe (any alternates usage is in the "satellite" clones anyway, 
and they will never write to the alternate object directory), and partly 
because at least for the kernel, we don't have branches that get reset in 
the main project, so there's no reason to fear that a "git repack -a -d" 
will ever screw up any of the satellite repositories even by mistake.

But for git projects, even alternates isn't safe, in case somebody bases 
their own work on a version of "pu" that eventually goes away (even with 
reflogs, pruning *eventually* takes place).

So I tend to think that alternates and shared object directories are 
really for "temporary" stuff, or for *managed* repositories that are at 
git *hosting* sites (eg repo.or.cz), and where there is some other safety 
involved, ie users don't actually access the object directories directly 
in any way.

So I've at least personally come to the conclusion that for a *developer* 
(as opposed to a hosting site!), shared object directories just never make 
sense. The downsides are just too big. Even alternates is something where 
you just need to be fairly careful!

		Linus