Carl Worth <cworth@xxxxxxxxxx> writes:
> ... 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.
-
: 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