From: Junio C Hamano <gitster@pobox.com> To: Jonathan Tan <jonathantanmy@google.com> Cc: git@vger.kernel.org Subject: Re: [PATCH 3/6] fetch-pack: refactor add_haves() Date: Thu, 08 Apr 2021 22:20:27 -0700 [thread overview] Message-ID: <xmqqlf9sniec.fsf@gitster.g> (raw) In-Reply-To: <b07e52ec18f46fb85d49ba0e1e6e8ad22845af9e.1617929278.git.jonathantanmy@google.com> (Jonathan Tan's message of "Thu, 8 Apr 2021 18:10:00 -0700") Jonathan Tan <jonathantanmy@google.com> writes: > A subsequent commit will need part, but not all, of the functionality in > add_haves(), so move some of its functionality to its sole caller > send_fetch_request(). > > Signed-off-by: Jonathan Tan <jonathantanmy@google.com> > --- > fetch-pack.c | 28 ++++++++++++---------------- > 1 file changed, 12 insertions(+), 16 deletions(-) > > diff --git a/fetch-pack.c b/fetch-pack.c > index 9f3901cdba..128ad47d2a 100644 > --- a/fetch-pack.c > +++ b/fetch-pack.c > @@ -1195,11 +1195,9 @@ static void add_common(struct strbuf *req_buf, struct oidset *common) > } > > static int add_haves(struct fetch_negotiator *negotiator, > - int seen_ack, > struct strbuf *req_buf, > - int *haves_to_send, int *in_vain) > + int *haves_to_send) > { > - int ret = 0; > int haves_added = 0; > const struct object_id *oid; > > @@ -1209,17 +1207,10 @@ static int add_haves(struct fetch_negotiator *negotiator, > break; > } > > - *in_vain += haves_added; > - if (!haves_added || (seen_ack && *in_vain >= MAX_IN_VAIN)) { > - /* Send Done */ > - packet_buf_write(req_buf, "done\n"); > - ret = 1; > - } > - > /* Increase haves to send on next round */ > *haves_to_send = next_flush(1, *haves_to_send); > > - return ret; > + return haves_added; > } OK, so the helper used to - send out have's - increment *in_vain with the number of have's sent out - decide when to send done and send it - increase haves-to-send for the next round. But the new version skips the second and third step, and let the caller be responsible for in_vain management. The only piece of information the caller needs to do so from this function is the number of have's we send out, so that is what we return from the function. > - /* Add initial haves */ > - ret = add_haves(negotiator, seen_ack, &req_buf, > - haves_to_send, in_vain); > + haves_added = add_haves(negotiator, &req_buf, haves_to_send); > + *in_vain += haves_added; > + if (!haves_added || (seen_ack && *in_vain >= MAX_IN_VAIN)) { > + /* Send Done */ > + packet_buf_write(&req_buf, "done\n"); > + done_sent = 1; > + } And indeed, this caller does the *in_vain management add_haves() used to do and give "done" as needed. > @@ -1322,7 +1318,7 @@ static int send_fetch_request(struct fetch_negotiator *negotiator, int fd_out, > die_errno(_("unable to write request to remote")); > > strbuf_release(&req_buf); > - return ret; > + return done_sent; And of course, the value returned by this function is if we sent "done", which is far easier to see with the new variable name. Again, very nicely done.
next prev parent reply other threads:[~2021-04-09 5:20 UTC|newest] Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-09 1:09 [PATCH 0/6] Push negotiation Jonathan Tan 2021-04-09 1:09 ` [PATCH 1/6] fetch-pack: buffer object-format with other args Jonathan Tan 2021-04-09 4:49 ` Junio C Hamano 2021-04-09 16:24 ` Jonathan Tan 2021-04-09 1:09 ` [PATCH 2/6] fetch-pack: refactor process_acks() Jonathan Tan 2021-04-09 5:08 ` Junio C Hamano 2021-05-03 16:30 ` Derrick Stolee 2021-04-09 1:10 ` [PATCH 3/6] fetch-pack: refactor add_haves() Jonathan Tan 2021-04-09 5:20 ` Junio C Hamano [this message] 2021-04-09 1:10 ` [PATCH 4/6] fetch-pack: refactor command and capability write Jonathan Tan 2021-04-09 5:27 ` Junio C Hamano 2021-04-09 1:10 ` [PATCH 5/6] fetch: teach independent negotiation (no packfile) Jonathan Tan 2021-04-09 5:41 ` Junio C Hamano 2021-04-09 16:38 ` Jonathan Tan 2021-05-03 15:25 ` Derrick Stolee 2021-05-03 15:40 ` Derrick Stolee 2021-05-03 21:52 ` Jonathan Tan 2021-04-09 1:10 ` [PATCH 6/6] send-pack: support push negotiation Jonathan Tan 2021-05-03 15:35 ` Derrick Stolee 2021-05-03 22:02 ` Jonathan Tan 2021-05-04 17:26 ` Derrick Stolee 2021-04-30 5:42 ` [PATCH 0/6] Push negotiation Junio C Hamano 2021-04-30 17:33 ` Derrick Stolee 2021-05-04 21:15 ` [PATCH v2 0/5] " Jonathan Tan 2021-05-04 21:15 ` [PATCH v2 1/5] fetch-pack: refactor process_acks() Jonathan Tan 2021-05-04 21:15 ` [PATCH v2 2/5] fetch-pack: refactor add_haves() Jonathan Tan 2021-05-04 21:16 ` [PATCH v2 3/5] fetch-pack: refactor command and capability write Jonathan Tan 2021-05-04 21:16 ` [PATCH v2 4/5] fetch: teach independent negotiation (no packfile) Jonathan Tan 2021-05-05 1:53 ` Junio C Hamano 2021-05-05 16:42 ` Derrick Stolee 2021-05-06 2:12 ` Junio C Hamano 2021-05-05 16:44 ` Derrick Stolee 2021-05-04 21:16 ` [PATCH v2 5/5] send-pack: support push negotiation Jonathan Tan
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=xmqqlf9sniec.fsf@gitster.g \ --to=gitster@pobox.com \ --cc=git@vger.kernel.org \ --cc=jonathantanmy@google.com \ --subject='Re: [PATCH 3/6] fetch-pack: refactor add_haves()' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).