git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jonathan Tan <jonathantanmy@google.com>
Cc: git@vger.kernel.org
Subject: Re: [RFC PATCH] transport: list refs before fetch if necessary
Date: Tue, 25 Sep 2018 16:09:49 -0700	[thread overview]
Message-ID: <xmqq8t3pnphe.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <20180925225355.74237-1-jonathantanmy@google.com> (Jonathan Tan's message of "Tue, 25 Sep 2018 15:53:55 -0700")

Jonathan Tan <jonathantanmy@google.com> writes:

> diff --git a/transport-helper.c b/transport-helper.c
> index 143ca008c8..7213fa0d32 100644
> --- a/transport-helper.c
> +++ b/transport-helper.c
> @@ -1105,6 +1105,7 @@ static struct ref *get_refs_list(struct transport *transport, int for_push,
>  }
>  
>  static struct transport_vtable vtable = {
> +	0,
>  	set_helper_option,
>  	get_refs_list,
>  	fetch,
> diff --git a/transport-internal.h b/transport-internal.h
> index 1cde6258a7..004bee5e36 100644
> --- a/transport-internal.h
> +++ b/transport-internal.h
> @@ -6,6 +6,12 @@ struct transport;
>  struct argv_array;
>  
>  struct transport_vtable {
> +	/**
> +	 * This transport supports the fetch() function being called
> +	 * without get_refs_list() first being called.
> +	 */
> +	unsigned fetch_without_list : 1;
> +
>  	/**
>  	 * Returns 0 if successful, positive if the option is not
>  	 * recognized or is inapplicable, and negative if the option
> diff --git a/transport.c b/transport.c
> index 1c76d64aba..ee8a78ff37 100644
> --- a/transport.c
> +++ b/transport.c
> @@ -703,6 +703,7 @@ static int disconnect_git(struct transport *transport)
>  }
>  
>  static struct transport_vtable taken_over_vtable = {
> +	1,
>  	NULL,
>  	get_refs_via_connect,
>  	fetch_refs_via_pack,
> @@ -852,6 +853,7 @@ void transport_check_allowed(const char *type)
>  }
>  
>  static struct transport_vtable bundle_vtable = {
> +	0,
>  	NULL,
>  	get_refs_from_bundle,
>  	fetch_refs_from_bundle,
> @@ -861,6 +863,7 @@ static struct transport_vtable bundle_vtable = {
>  };
>  
>  static struct transport_vtable builtin_smart_vtable = {
> +	1,
>  	NULL,
>  	get_refs_via_connect,
>  	fetch_refs_via_pack,

Up to this point I think I understand the change.  We gain one new
trait for each transport, many of the transport cannot run fetch
without first seeing the advertisement, some are OK, so we have 0 or
1 in these vtables as appropriately.

> @@ -1224,6 +1227,15 @@ int transport_fetch_refs(struct transport *transport, struct ref *refs)
>  	struct ref **heads = NULL;
>  	struct ref *rm;
>  
> +	if (!transport->vtable->fetch_without_list)
> +		/*
> +		 * Some transports (e.g. the built-in bundle transport and the
> +		 * transport helper interface) do not work when fetching is
> +		 * done immediately after transport creation. List the remote
> +		 * refs anyway (if not already listed) as a workaround.
> +		 */
> +		transport_get_remote_refs(transport, NULL);
> +

But this I do not quite understand.  It looks saying "when asked to
fetch, if the transport does not allow us to do so without first
getting the advertisement, lazily do that", and that may be a good
thing to do, but then aren't the current set of callers already
calling transport-get-remote-refs elsewhere before they call
transport-fetch-refs?  IOW, I would have expected to see a matching
removal, or at least a code that turns an unconditional call to
get-remote-refs to a conditional one that is done only for the
transport that lacks the capability, or something along that line.

... ah, do you mean that this is not a new feature, but is a bugfix
for some callers that are not calling get-remote-refs before calling
fetch-refs, and the bit is to work around the fact that some
transport not just can function without get-remote-refs first but do
not want to call it?

IOW, I am a bit confused by this comment (copied from an earlier part)

> +	/**
> +	 * This transport supports the fetch() function being called
> +	 * without get_refs_list() first being called.
> +	 */

Shouldn't it read more like "this transport does not want its
get-refs-list called when fetch-refs is done"?

I dunno.


>  	for (rm = refs; rm; rm = rm->next) {
>  		nr_refs++;
>  		if (rm->peer_ref &&

  reply	other threads:[~2018-09-25 23:09 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-25 22:53 [RFC PATCH] transport: list refs before fetch if necessary Jonathan Tan
2018-09-25 23:09 ` Junio C Hamano [this message]
2018-09-27 19:24 ` [RFC PATCH v2 0/4] Avoid ls-refs when possible in protocol v2 Jonathan Tan
2018-09-27 19:24   ` [RFC PATCH v2 1/4] transport: allow skipping of ref listing Jonathan Tan
2018-09-27 19:24   ` [RFC PATCH v2 2/4] transport: do not list refs if possible Jonathan Tan
2018-09-27 21:38     ` Stefan Beller
2018-10-07  0:53       ` Junio C Hamano
2018-09-27 19:24   ` [RFC PATCH v2 3/4] transport: list refs before fetch if necessary Jonathan Tan
2018-09-27 19:24   ` [RFC PATCH v2 4/4] fetch: do not list refs if fetching only hashes Jonathan Tan
2018-09-27 21:43     ` Stefan Beller
2018-09-28 17:50       ` Jonathan Tan
2018-09-27 20:53   ` [RFC PATCH v2 0/4] Avoid ls-refs when possible in protocol v2 Junio C Hamano

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqq8t3pnphe.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=jonathantanmy@google.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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 NNTP newsgroup(s).