Re: [RFC PATCH] fetch-pack: space out sent "haves" in negotiation

On Wed, 23 May 2018 12:42:10 +0900 Junio C Hamano wrote: > Somehow this feels more like a WIP than RFC, primarily for two > reasons. It was unclear what "edge" computation is trying to do; it > seems way under-explained, especially the part that takes min-max > while. merging two candidates.

Re: [RFC PATCH] fetch-pack: space out sent "haves" in negotiation

Jonathan Tan writes: > Makefile | 1 + > fetch-negotiator.c | 309 + > fetch-negotiator.h | 40 ++ > fetch-pack.c | 174 ++--- > object.h | 1 + > 5 files changed, 392

Re: [RFC PATCH] fetch-pack: space out sent "haves" in negotiation

Jonathan Tan writes: > I was thinking about fetch negotiation in some non-ideal situations > (specifically, when the client repo contains two or more independent > branches that meet only somewhere far in the past) and thought about > skipping over intermediate commits,

Re: [RFC PATCH] fetch-pack: space out sent "haves" in negotiation

Hi Jonathan, > I wouldn't characterize the errors as "off by one errors". Yes, I put it in quotes but realized that would not convey it very well. > They are > more like...let me use a diagram: > > A > |\ > B D > | | > C E > > Suppose we know that the server does not have A, has C, and may or

Re: [RFC PATCH] fetch-pack: space out sent "haves" in negotiation

On Mon, 21 May 2018 15:57:18 -0700 Stefan Beller wrote: > In an ideal world, the server and client would both estimate the potential > reduction of the packfile to send, and base the decision if to continue > negotiating on the trade off if the packfile reduction savings are

Re: [RFC PATCH] fetch-pack: space out sent "haves" in negotiation

Hi Jonathan, On Mon, May 21, 2018 at 1:43 PM, Jonathan Tan wrote: > I was thinking about fetch negotiation in some non-ideal situations > (specifically, when the client repo contains two or more independent > branches that meet only somewhere far in the past) and

[RFC PATCH] fetch-pack: space out sent "haves" in negotiation

I was thinking about fetch negotiation in some non-ideal situations (specifically, when the client repo contains two or more independent branches that meet only somewhere far in the past) and thought about skipping over intermediate commits, using exponentially larger skips as we proceed, when