Re: [PATCH 2/6] fetch-pack: truly stop negotiation upon ACK ready

2018-06-05 Thread Jonathan Tan
On Tue, 5 Jun 2018 16:16:34 -0700 Jonathan Nieder wrote: > Hi, > > Jonathan Tan wrote: > > > When "ACK %s ready" is received, find_common() clears rev_list in an > > attempt to stop further "have" lines from being sent [1]. This appears > > to work, despite the invocation to mark_common() in

Re: [PATCH 2/6] fetch-pack: truly stop negotiation upon ACK ready

2018-06-05 Thread Jonathan Nieder
Jonathan Nieder wrote: > Jonathan Tan wrote: >> The corresponding code for protocol v2 in process_acks() does not have >> the same problem, because the invoker of process_acks() >> (do_fetch_pack_v2()) proceeds immediately to processing the packfile > > nit: s/proceeds/procedes/ Whoops. My

Re: [PATCH 2/6] fetch-pack: truly stop negotiation upon ACK ready

2018-06-05 Thread Jonathan Nieder
Hi, Jonathan Tan wrote: > When "ACK %s ready" is received, find_common() clears rev_list in an > attempt to stop further "have" lines from being sent [1]. This appears > to work, despite the invocation to mark_common() in the "while" loop. Does "appears to work" mean "works" or "doesn't work

[PATCH 2/6] fetch-pack: truly stop negotiation upon ACK ready

2018-06-04 Thread Jonathan Tan
When "ACK %s ready" is received, find_common() clears rev_list in an attempt to stop further "have" lines from being sent [1]. This appears to work, despite the invocation to mark_common() in the "while" loop. Though it is possible for mark_common() to invoke rev_list_push() (thus making rev_list