Re: Unresolved issues #2 (shallow clone again)

From: Martin Langhoff <martin.langhoff@gmail.com>
Date: May 6, 2006, 06:23 UTC
Message-ID: <46a038f90605052323o29f8bfadr7426f97d8dfc2319@mail.gmail.com>
In-Reply-To: <Pine.LNX.4.64.0605050848230.3622@g5.osdl.org>

On 5/6/06, Linus Torvalds <torvalds@osdl.org> 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...

Show 5 quoted lines

> 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