git@vger.kernel.org mailing list mirror (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 1/2] fetch-object: provide only one fetching function
Date: Wed, 12 Sep 2018 14:50:38 -0700	[thread overview]
Message-ID: <xmqqefdyjsgh.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <72399daf65b9c0a7ed12589584f5108a9ff6fc26.1536767071.git.jonathantanmy@google.com> (Jonathan Tan's message of "Wed, 12 Sep 2018 08:47:37 -0700")

Jonathan Tan <jonathantanmy@google.com> writes:

> fetch-object.h currently provides two functions (fetch_object() and
> fetch_objects()) that could be replaced by a single, more flexible
> function. Replace those two functions with the more flexible function.

The latter half of the first sentence and the second sentence are
pretty-much repeating the same thing.  

I think you wanted to justify two changes:

 (1) There are two helpers.  fetch_object() fetches a single object
     from a given remote; fetch_objects() fetches a set of objects
     from a given remote.  It is not like the former is implemented
     as a specialization of the latter (i.e. passing length=1
     array), and it is not like the former is optimized specially
     for a single object fetch that cannot be made into such a thin
     wrapper.  It is not like the latter is implemented as a
     repeated call to the former in a loop, either.  There is no
     justification to keep two independent implementations, and
     using a single helper that can be used by all the callers of
     these two would make sense.

 (2) The variant that fetches multiple objects takes oid_array.  To
     be used by all the existing callers of these two helpers, it is
     better to use a different calling convention, namely, a array[]
     and its length passed as separate parameters.
     
Instead of explaining why the new convention is better to justify
(2), the above three lines handwave by saying "more flexible"
twice.  We should do better.

	fetch-object: unify fetch_object[s] functions

	There are fetch_object() and fetch_objects() helpers in
	fetch-object.h; as the latter takes "struct oid_array",
	the former cannot be made into a thin wrapper around the
	latter without an extra allocation and set-up cost.

	Update fetch_objects() to take an array of "struct
	object_id" and number of elements in it as separate
	parameters, remove fetch_object(), and adjust all existing
	callers of these functions to use the new fetch_objects().

perhaps?

> diff --git a/sha1-file.c b/sha1-file.c
> index 97b742384..2edf4564f 100644
> --- a/sha1-file.c
> +++ b/sha1-file.c
> @@ -1317,7 +1317,7 @@ int oid_object_info_extended(struct repository *r, const struct object_id *oid,
>  			 * TODO Pass a repository struct through fetch_object,
>  			 * such that arbitrary repositories work.
>  			 */
> -			fetch_object(repository_format_partial_clone, real->hash);
> +			fetch_objects(repository_format_partial_clone, real, 1);
>  			already_retried = 1;
>  			continue;
>  		}
> diff --git a/unpack-trees.c b/unpack-trees.c
> index f25089b87..82a83dbc6 100644
> --- a/unpack-trees.c
> +++ b/unpack-trees.c
> @@ -392,7 +392,7 @@ static int check_updates(struct unpack_trees_options *o)
>  		}
>  		if (to_fetch.nr)
>  			fetch_objects(repository_format_partial_clone,
> -				      &to_fetch);
> +				      to_fetch.oid, to_fetch.nr);
>  		fetch_if_missing = fetch_if_missing_store;
>  		oid_array_clear(&to_fetch);
>  	}

Changes to these two callers do explain why <ptr, nr> is an
interface that is easier to use.  Those who already have an
oid_array can pass its fields as separate parameters without too
much trouble, and those who only have an oid (or an array of oid and
knows how many are in the array) do not have to wrap them into an
oid_array.

Thanks.

  reply	other threads:[~2018-09-12 21:50 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-12 15:47 [PATCH 0/2] Bugfix for partial clones and ref-in-want servers Jonathan Tan
2018-09-12 15:47 ` [PATCH 1/2] fetch-object: provide only one fetching function Jonathan Tan
2018-09-12 21:50   ` Junio C Hamano [this message]
2018-09-13 18:09     ` Jonathan Tan
2018-09-13 20:55       ` Junio C Hamano
2018-09-12 15:47 ` [PATCH 2/2] fetch-object: set exact_oid when fetching 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=xmqqefdyjsgh.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.
Code repositories for project(s) associated with this public 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).