Re: Recent unresolved issues: shallow clone

From: Junio C Hamano <junkio@cox.net>
Date: Apr 15, 2006, 02:11 UTC
Message-ID: <7vwtdrlh8w.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <7vr73zn0rb.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano <junkio@cox.net> writes:

Show 7 quoted lines

> Maybe after the update to G happens (which means you now have C,
> F, G but not A B D E commits), the client side could enumerate
> commits on "rev-list ^C G" and cauterize the ones with missing
> parents (in this case, F does not have one of its parents).
> While doing this would help keeping the resulting commit
> ancestry sane, it does not solve the problem of missing blobs
> and trees.  See below.

Actually, it is more involved than the above.

The sender would give you A B D E as well, so we would not be able to cauterise at F; instead you would do so at A, making your shallow clone a bit deeper. When you look at the objects the parent gave you by running "rev-list ^C G", you would notice that you do not have any of real parents of A, and add a new graft. While you are at it, you would hopefully notice that the real parent of commit C is something you now have -- so you remove the graft entry for C.

However, depending on what you care about more, having the sender not to send the side branch and cauterising the result at F _might_ be a better thing to do. This is probably quite involved and I offhand would not know how to efficiently compute.