Re: [PATCH 6/6] Teach core object handling functions about gitlinks

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

Linus Torvalds wrote:

quoted

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!).

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