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

[Linus Torvalds <torvalds@linux-foundation.org>]

On Thu, 12 Apr 2007, Dana How wrote:
> 
> These arguments all seem pretty convincing to me --
> maybe the problem is that I'm not a "*developer*" right now.
> Instead I'm part of a multi-developer *site*.

Yes.

The issues for hosting sites are very different from the issues of 
individual developers having their own git repositories, and I agree 100% 
that both alternates and shared object directories make tons of sense for 
hosting.

> Below I talk about a possible way we could use git
> without changing it (since I recognize this would be a minority usage
> pattern).

I hope it wouldn't even be a minority usage pattern. I am a firm believer 
that distributed SCM's and git in particular makes a lot more sense for 
source control hosting than CVS or SVN do. I'm really disappointed with 
things like sourceforge, and part of the problem is literally that a 
centralized SCM is really *fundamentally* wrong for a hosting entity. 

Using a distributed SCM just makes _so_ much more sense for hosting 
projects, and I've actually very much wanted to try to make sure that git 
can help people who host things. 

It's not my *own* primary use, but I think it's a very important usage 
pattern, even though it's very different froma "normal developer" private 
sandbox case.

So I think your case is really very interesting. I'd love to help figure 
out how to help you guys with git, but because it's not how I personally 
work, I can really just try to help when you actually hit a problem - 
you'll have to figure out what your usage patterns actually are on your 
own ;)

And btw, I think the shared object model really works very well, but I 
think it has to be paired with some stricter rules than people who use 
their own repos tend to have. For example, end-point developers have 
become very used to rebasing and generally rewriting history (or just 
resetting to an older state), and that's something that works find in a 
"local repository" setup, but it's also the kinds of patterns that can 
really screw you in a hosted and shared-object environment.

As to your two setups: I would suggest you go with the "hidden" shared 
version (ie people use the remote access pull/push to a server, and the 
*server* uses a shared object repository for multiple repositories), 
rather than having a user-visible globally shared object directory. Even 
with sticky bits and controlled group access etc, I think it's just safer 
to have that extra level of indirection.

(Partly because a globally visible shared object directory also implies 
that you'd use a networked filesystem, and I suspect a lot of developers 
would actually be a lot happier having their own development repositories 
on their own local disks, or at least some "group disk", rather than have 
one big and performance-critical network share. Even if you use some 
competent NetApp box and a modern network filesystem, it's just one less 
critical infrastructure piece that needs to be really beefy).

		Linus