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@xxxxxxxxxxxxxxxxxxxxxxxx>).
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.
> '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...
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html