Linus Torvalds wrote: >> 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. > Ok, but couldn't this be considered a variation of a lightweight checkout? The only reason I'm worried about this is the case where the superproject contains *thousands* of subprojects. Eg, a superproject for all repo.or.cz projects. Say in a day 200 projects get updated with a few commits - do you have to do 200 pulls or just one? But maybe that problem can be solved in another way, or maybe it won't really hurt so much in practice and still be faster/more efficient than rsync mirroring. This is especially the case in concert with gittorrent, which will need modifications to support sharing multiple repositories (not that that's a huge issue, given there's no implementation yet). >> 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". > Well fsck can be fixed easily enough to not descend, like lightweight checkouts. What I really want to avoid is the situation where you can't checkout, even though you didn't indicate a shallow/lightweight clone. What else might this decision impact? Obviously with a smaller base you have fewer delta targets, though that's probably not a real issue. Sam. - 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