* pack negotiation algorithm between 2 share-nothing repos
@ 2015-08-12 11:27 Duy Nguyen
2015-08-12 15:55 ` Junio C Hamano
0 siblings, 1 reply; 3+ messages in thread
From: Duy Nguyen @ 2015-08-12 11:27 UTC (permalink / raw)
To: Git Mailing List
This is a corner case that has a real use case:
git clone linux-2.6.git
cd linux-2.6
git remote add history git-history.git
git fetch history
# graft graft graft
Because history.gi and linux-2.6.git have nothing in common, the
server side keeps asking for more "have"s and the client keeps sending
in "git fetch history". Negotiation phase takes longer than my
patience so I abort it, hack git to send no "have"s and retry.
I know this is a corner case, but because it has a valid use case,
maybe we should do something about it. Immediate reaction is to add an
option to send no "have"s. But maybe you guys have better ideas.
PS. I know i'm behind my git inbox. Looking into it soon.
--
Duy
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: pack negotiation algorithm between 2 share-nothing repos
2015-08-12 11:27 pack negotiation algorithm between 2 share-nothing repos Duy Nguyen
@ 2015-08-12 15:55 ` Junio C Hamano
2015-08-26 16:49 ` Junio C Hamano
0 siblings, 1 reply; 3+ messages in thread
From: Junio C Hamano @ 2015-08-12 15:55 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Git Mailing List
Duy Nguyen <pclouds@gmail•com> writes:
> I know this is a corner case, but because it has a valid use case,
> maybe we should do something about it. Immediate reaction is to add an
> option to send no "have"s. But maybe you guys have better ideas.
This and similar corner cases were discussed in very early days of
Git.
One interesting idea floated back then but was not pursued was to
dig and send have's sparsely and then back up. Instead of digging
and sending _all_ commits in a contiguous history, after sending the
tip, you skip the commits from the history before sending the next
one, and progressively make the skipping larger (e.g. Fibonacci, or
exponential). You need to remember what you sent and for each of
what you sent its topologically-oldest descendant you sent earlier
that you heard the other side does not have.
Then, when you get an Ack, you know a stretch of history between a
commit that is known to be common (i.e. the one you heard an Ack
just now) and its descendant that is known only to you (i.e. the
topologically-oldest one you remember that you did send and they
didn't say is common). At that point, you and the other end can
bisect that range.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: pack negotiation algorithm between 2 share-nothing repos
2015-08-12 15:55 ` Junio C Hamano
@ 2015-08-26 16:49 ` Junio C Hamano
0 siblings, 0 replies; 3+ messages in thread
From: Junio C Hamano @ 2015-08-26 16:49 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Git Mailing List, Stefan Beller, Thomas Rast
Junio C Hamano <gitster@pobox•com> writes:
> Duy Nguyen <pclouds@gmail•com> writes:
>
>> I know this is a corner case, but because it has a valid use case,
>> maybe we should do something about it. Immediate reaction is to add an
>> option to send no "have"s. But maybe you guys have better ideas.
>
> This and similar corner cases were discussed in very early days of
> Git.
>
> One interesting idea floated back then but was not pursued was to
> dig and send have's sparsely and then back up. Instead of digging
> and sending _all_ commits in a contiguous history, after sending the
> tip, you skip the commits from the history before sending the next
> one, and progressively make the skipping larger (e.g. Fibonacci, or
> exponential). You need to remember what you sent and for each of
> what you sent its topologically-oldest descendant you sent earlier
> that you heard the other side does not have.
>
> Then, when you get an Ack, you know a stretch of history between a
> commit that is known to be common (i.e. the one you heard an Ack
> just now) and its descendant that is known only to you (i.e. the
> topologically-oldest one you remember that you did send and they
> didn't say is common). At that point, you and the other end can
> bisect that range.
If anybody is interested, here is a good place to start:
http://thread.gmane.org/gmane.comp.version-control.git/96149/focus=102485
[Cc'ed Stefan as I think he was collecting possible enhancement to
put in the protocol v2].
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-08-26 16:50 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-08-12 11:27 pack negotiation algorithm between 2 share-nothing repos Duy Nguyen
2015-08-12 15:55 ` Junio C Hamano
2015-08-26 16:49 ` Junio C Hamano
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox