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 - 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