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

[Sam Vilain <sam@vilain.net>]

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.