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

On 4/11/07, Sam Vilain [off-list ref] wrote:

Linus Torvalds wrote:

quoted

quoted

Does this consider the case where the intent of the subprojects are to
collate multiple, small projects into one bigger project?

In that case, you might want to keep all of the subprojects in the same
git repository.

I assume you mean "you might want to keep all of the subprojects' objects
in the same git object directory".

And yes, that's absolutely true, but it's technically no different from
just using GIT_OBJECT_DIRECTORY to share objects between totally unrelated
projects, or using git/alternates to share objects between (probably
*less* unrelated repositories, but still clearly individual repos).

Would that be the only distinction?

Would submodules be descended into for object reachability questions?

quoted

So the main point of superproject/subprojects is to allow independence
(because independence is what allows it to scale), but there is nothing to
say that things *have* to kept totally isolated.

I'm particularly interested in repositories with, say, thousands of
submodules but only a few hundred meg. I really want to avoid the
situation where each of those submodules gets checked or descended into
separately for updates etc.

This seems slightly related to the hazy picture I'm forming of how
I'd like to use git at our site.  Essentially, everyone would have their
own working tree with .git directory, but .git/objects is a symlink
to a shared object repository.  How do you fully run git-fsck on this
shared object repository?  The actual heads (roots) are distributed amongst
many .git/refs directories (I suppose you could do something akin
to git-fsck $(cat /somepaths*/.git/refs/*), but that means you know
where all the repositories are).  So in this setup, maybe I'd want to run
fsck twice: the first time checking everything but not complaining about
dangling commit objects [but listing them?], and maybe a 2nd finding
all these in the users' repos [still need to know where these are].
Please note this is just a thought experiment at this point.

Anyway,  git started out with a 1:1 relationship between working tree,
index, and object repository. Various things could weaken that --
alternates, subprojects with different relationships to their object
repositories, etc. -- so special commands like git fsck which
focus mostly on the object repository may need a little tweaking eventually.

-- 
Dana L. How  danahow@gmail.com  +1 650 804 5991 cell