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

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

On Fri, 13 Apr 2007, Rogan Dawes wrote:
> 
> Would it not make sense for a hosting environment to say, if you are using
> alternates, or shared object directories, then you need to include *all* the
> refs in *all* the projects if you ever do an fsck?

Yes. And it shouldn't be hard to add support to do it. It's just not been 
done.

A lot of git programs already take refs on stdin, but fsck just doesn't do 
it (it can do it from the command line, but you'd run out of command line 
space very quickly).

More natural would be to just list all the git repos by git repo pathname 
(and there, usually the command line probably *is* long enough), but 
somebody would just have to do it. It's probably not very much code: just 
iterate over each repo both when adding refs and when actually doing the 
fsck itself.

> I'm not sure how well git will scale in this case, although it just should be
> a matter of how well git scales to dealing with a single project with tens of
> thousands of refs/tags/etc. The only problem might be in passing all those
> refs/tags to fsck in one go. STDIN, I guess?

For a real shared object directory, passing the refs to stdin (and 
teaching fsck about a "--stdin" flag) would be consistent with what we do 
for many other commands, so yes, that would work.

However, fsck actually tends to want not just the refs, but actually 
things like the index files and reflog files too, because those add other 
reachability info, which is why it's probably more natural to just give 
fsck the list of related repositories and let it figure them out.

That's also what you'd want to do for "alternates", since now there is no 
longer a single object directory either, but multiple separate (but 
related) ones.

Somebody would just have to write the code.. The basic rules are really 
all in "git/builtin-fsck.c": cmd_fsck(). Hint hint.

			Linus