[ Dang. Power failure in the middle of writing emails. Can't remember 
  which one was lost. Am rewriting some of this reply in abbreviated form.  ]

On Thu, 12 Apr 2007, Sam Vilain wrote:
quoted text
>
> Linus Torvalds wrote:
> > So there's a very real issue where a repository with submodules still 
> > "works", even with a .gitmodules file that is totally scrogged and doesn't 
> > have the right information (yet), it's just that it may simply not be able 
> > to do all the operations because it cannot figure out where to pull 
> > missing subproject data from etc..
> >   
> 
> Whoa... "missing" subproject data?

Absolutely. Not just subproject data. The whole subproject is often 
missing.

If I fetch the KDE superproject, I generally do *not* want every single 
subproject. In fact, I'd likely just want one or two subprojects.

The notion that all subprojects are populated is a *bug*. I would 
personally refuse to use such a setup. Even CVS can handle that just fine, 
we certainly don't want to be worse than CVS here.

If you just track a project, it's quite common to only check out the "src" 
module, and *not* fetch things like the "validation" or "test" module if 
you're just following along. 

Or you might fetch the "kdebase" module, but that sure doesn't mean that 
you want all the other ones (kdevelop source code? full kdelibs sources? 
If I'm only interested in kwin and some other random app? No thanks!).

quoted text
> Surely, unless you're doing lightweight/shallow clones, if you have a
> gitlink you've also got the dependent repository? Otherwise the
> reachability rule will be broken.

The reachability rule *must* be breakable. That's why fsck currently 
doesn't care AT ALL.

It's much better to break that rule than to even check it! I'd rather 
leave fsck like it is now, than to *ever* fix it, if the "fix" involves 
"you have to always fetch all submodules to shut fsck up".

		Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html