Re: Unresolved issues #2 (shallow clone again)

From: Junio C Hamano <junkio@cox.net>
Date: May 5, 2006, 00:25 UTC
Message-ID: <7v1wv92u7o.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <87mzdx7mh9.wl%cworth@cworth.org>

Carl Worth <cworth@cworth.org> writes:

Show 21 quoted lines

> ... So the conversation changes from "I WANT
> <fetch-heads> and I HAVE <heads>" to one of "I WANT <fetch-heads>, and
> I HAVE <heads>, except that I'm MISSING <cauterized-commits>".
>
> Finally, whenever a fetch receives an commit object that is in its
> list of cauterized commits, it should remove that commit from the
> list. This allows a shallow clone to be naturally migrated to
> something unshallow. And the user can do this as incrementally as
> desired based on the need to see more history:
>
> get a bit:
> 	git fetch somewhere --since=2.weeks.ago
>
> then a bit more:
> 	git fetch somewhere --since=1.year.ago
>
> then get it all:
> 	git fetch somewhere
>
> Maybe that's no different from Junio's original proposal. If not, what
> do you see in the above that wouldn't work?

Lack of actual code to do all that ;-)

Jokes aside, I think listing the updated conversation elements like you did above is a good step forward.

The vocabulary we would want from the requestor side is probably (at least):

	I WANT to have these
        I HAVE these
        I'm MISSING these
        Don't bother with these this time around (--since, ^v2.6.16, ...)

I am not sure how we would want to encode the last one and have it used by rev-list on the upload-pack end safely and sanely.

And the responder side needs to be able to say, "Now you are MISSING these, remember it and tell me you are missing them next time you make a request". That would be, in the simplest case, a list of commit IDs to cauterize, but I am not sure what is the right way to come up with that list. Especially I do not know if --boundary would/should work with --objects.