Junio C Hamano wrote: > Even if it is conservative, I wonder if it is truly a good idea to > make it exponentially grow forever from that point of view. Would > it give essentially the same result to you if we discard the patch > in question and just raise LARGE_FLUSH to 10k instead? I don't think it would be essentially the same result. As discussed before, unlike the bidi (ssh:// and git:// protocols) case, linear growth is expensive in the stateless-rpc (https://) case --- each round of negotiation requires re-sending the existing 'have's and requires the peer repeatedly processing this increasingly large list of 'have's. For comparison, in the bidi case, linear growth of next_flush means sending a bounded number of 'have's per round and is quite sensible. In the stateless-rpc case, linear growth means getting a bounded number of 'have's worth of benefit (new 'have's) in each round, in exchange for a linearly increasing cost (existing 'have's). That is a high cost for limited benefit. Exponential growth is a better deal. Jonathan -- To unsubscribe from this list: 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