On 5/6/06, Linus Torvalds <torvalds@xxxxxxxx> 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 - : 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