Re: Unresolved issues #2 (shallow clone again)

On 5/6/06, Linus Torvalds [off-list ref] wrote:

Of course, that would require another slight difference to "rev-list.c",
where we'd only recurse into trees of selected commit objects (ie we'd
have to mark the HAVE/WANT commits specially, but it's not exactly
complex either).

Would it make sense to make all the shallow clone clone machinery walk
everything and trim only blob objects? In that case, all the machinery
that walks commits/trees would remain intact -- we only have to deal
with the case of not having blob objects, which affects less
codepaths.

It means that for a merge or checkout involving stuff we "don't have",
it's trivial to know we are missing, and so we can  attempt a fetch of
the missing objects or tell the user how to request them them before
retrying.

And in any case commits and trees are lightweight and compress well...

Of course, the complexity of _both_ of these approaches is really in the
fsck stage, and all the crud you need to then do other things with these
pared-down repos. For example, do you allow cloning? And do you just
automatically notice that you're cloning a shallow repo, and only do a
shallow clone. Etc etc..

Definitely.

cheers,


martin