Re: Change set based shallow clone

From: Martin Langhoff <martin.langhoff@gmail.com>
Date: Sep 8, 2006, 03:54 UTC
Message-ID: <46a038f90609072054u5ec8bc46x9878a601953b2c5d@mail.gmail.com>
In-Reply-To: <7vpse7tjp0.fsf@assigned-by-dhcp.cox.net>

On 9/8/06, Junio C Hamano <junkio@cox.net> wrote: ...

Show 6 quoted lines

> Anyway, it is a useful feature, an important operation, and
> it involves a lot of thinking (and hard work, obviously).
>
> I will not think about this anymore, until I have absolutely
> nothing else to do for a solid few days, but you probably
> haven't read this far ;-).

For when you come back, then. I agree this is rather complicated, so much so that I suspect that we may be barking up the wrong tree.

People who want shallow clones are actually asking for a "light" clone, in terms of "how much do I need to download". If everyone has the whole commit chain (but may be missing olden blobs, and even trees), the problem becomes a lot easier.

On the wire, all the client needs to say from root commit X to later commits A, B, C, D, can I have all the relevant blobs? (Some may end up being resent, but that's a tradeoff).

On the server side, keeping commits (and/or trees) in a segregated pack makes sense as an optimization. On the client side, a similar segregated pack for the 'known blobless' commits/trees may make sense to be able to be able treat ops on the blobless part of history differently.

{From a user interaction point of view, it is also easier to error out saying "don't have it, but you'll get it if you ask for history from [SHA1] onwards".}

just my .2