Re: 'sparse' clone idea

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jun 14, 2006, 09:20 UTC
Message-ID: <Pine.LNX.4.63.0606141110001.15673@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <e6oh2g$ngh$1@sea.gmane.org>

Hi,

On Wed, 14 Jun 2006, Jakub Narebski wrote:

> I wonder if 'sparse clone' idea described below would avoid the most
> difficult part of 'shallow clone' idea, namely the [sometimes] need to
> un-cauterize history. See: (<7vac8lidwi.fsf@assigned-by-dhcp.cox.net>).

I do not think that is the hardest problem. The hardest thing is to tell the server in an efficient manner which objects we have.

Example:

A - B - C - D
    ^ cutoff
        ^ current HEAD

Suppose B is your fake root, C is your HEAD, you want to fetch D. Now, make it a difficult example: both A and D contain a certain blob Z, but neither B nor C do. You have to tell the server _in an efficient manner_ to send Z also.

And by efficient manner I mean: you may not bring the server down just because 5 people with shallow clones decide to fetch from it.

Show 10 quoted lines

> 'sparse clone' begins like 'shallow clone': full history is copied down to
> specified point of history (cut-off or cauterization point for shallow
> clone), but instead of cauterizing the history from that point downwards,
> the history is simplified using grafts.
> 
> In the sparse part we need:
>  * all commits pointed by tags (if we clone/copy tags) 
>    and other refs (if we clone/copy those tags)
>  * merge bases for all commits in full, and in the sparse part,
>    _including_ merge bases themselves

Hmmm. You cannot know _all_ merge bases beforehand, because you do not decide where other people fork off.

>  * all roots

Why?

> Commits in sparse part would be connected like in original history, only
> skipping "uniteresting" commits.

Interesting idea, though I do not think it solves the most pressing problems we have with shallow clones.

Ciao, Dscho

P.S.: I think the problems of a lazy clone are much easier to solve...