git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
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.


  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

git@vger.kernel.org list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ https://public-inbox.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://7fh6tueqddpjyxjmgtdiueylzoqt6pt7hec3pukyptlmohoowvhde4yd.onion/inbox.comp.version-control.git
	nntp://ie5yzdi7fg72h7s4sdcztq5evakq23rdt33mfyfcddc5u3ndnw24ogqd.onion/inbox.comp.version-control.git
	nntp://4uok3hntl7oi7b4uf4rtfwefqeexfzil2w6kgk2jn5z2f764irre7byd.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git
 note: .onion URLs require Tor: https://www.torproject.org/

code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git