From: Martin Langhoff Date: Sat, 06 May 2006 06:23:03 GMT Subject: Re: Unresolved issues #2 (shallow clone again) Message-ID: <46a038f90605052323o29f8bfadr7426f97d8dfc2319@mail.gmail.com> In-Reply-To: On 5/6/06, Linus Torvalds 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