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