Fredrik Medley <fredrik.medley@xxxxxxxxx> writes:
> With uploadpack.allowreachablesha1inwant configuration option set on the
> server side, "git fetch" can make a request with a "want" line that names
> an object that has not been advertised (likely to have been obtained out
> of band or from a submodule pointer). Only objects reachable from the
> branch tips, i.e. the union of advertised branches and branches hidden by
> transfer.hiderefs, will be processed. Note that there is an associated
> cost of having to walk back the hstory to check the reachability.
s/hstory/history/
>
> This feature can be used when obtaining the content of a certain commit,
> for which the sha1 is known, without the need of cloning the whole
> repository, especially if a shallow fetch is used. Useful cases are e.g.
> repositories containing large files in the history, fetching only the
> needed data for a submodule checkout, when sharing a sha1 without telling
> which exact branch it belongs to and in Gerrit, if you think in terms of
> commits instead of change numbers. (The Gerrit case has already been
> solved through allow-tip-sha1-in-want as every change has a ref.)
>
> Signed-off-by: Fredrik Medley <fredrik.medley@xxxxxxxxx>
> ---
Much easier to read and understand.
> Documentation/config.txt | 6 ++++++
> fetch-pack.c | 9 ++++++--
> t/t5516-fetch-push.sh | 55 ++++++++++++++++++++++++++++++++++++++++++++++++
> upload-pack.c | 19 ++++++++++++-----
> 4 files changed, 82 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 2e5ceaf..76cd713 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -2538,6 +2538,12 @@ uploadpack.allowtipsha1inwant::
> of a hidden ref (by default, such a request is rejected).
> see also `uploadpack.hideRefs`.
>
> +uploadpack.allowreachablesha1inwant::
I know that the existing allowtipsha1inwant is spelled that way, and
it may be better done as a separate clean-up patch (either before or
after this step), but the documentation and the first line of the
log message would be easier to read with
uploadpack.allowReachableSHA1InWant
I'd think.
> + Allow `upload-pack` to accept a fetch request that asks for an
> + object that is reachable from any ref tip. However, note that
> + calculating object reachability is computationally expensive.
> + Defaults to `false`.
s/<TAB>object/<SPACE>object/
> diff --git a/fetch-pack.c b/fetch-pack.c
> index 48526aa..fb01b6c 100644
> --- a/fetch-pack.c
> +++ b/fetch-pack.c
> @@ -43,7 +43,7 @@ static int marked;
> #define MAX_IN_VAIN 256
>
> static struct prio_queue rev_list = { compare_commits_by_commit_date };
> -static int non_common_revs, multi_ack, use_sideband, allow_tip_sha1_in_want;
> +static int non_common_revs, multi_ack, use_sideband, allow_tip_sha1_in_want, allow_reachable_sha1_in_want;
Do we anticipate need for other variations of "allowing bare SHA-1
that they did not advertise" in the future?
That is a trick question. We didn't anticipate it, and that is why
the existing feature squats on a whole integer variable. And we are
paying the price of that lack of foresight by having to enhance with
this patch. So the only sensible answer to that question is "we
might need to keep this extensible".
How about renaming the existing allow_tip_sha1_in_want to something
more generic to cover all such needs, e.g.
#define ALLOW_TIP 01
#define ALLOW_REACHABLE 02
static int allow_request_with_bare_object_name;
Then you do not have to write (tip || reachable), and more
importantly, you do not have to force the next person to update that
to (tip || reachable || his_new_kind), I would think.
> @@ -789,6 +796,8 @@ static int upload_pack_config(const char *var, const char *value, void *unused)
> {
> if (!strcmp("uploadpack.allowtipsha1inwant", var))
> allow_tip_sha1_in_want = git_config_bool(var, value);
> + else if (!strcmp("uploadpack.allowreachablesha1inwant", var))
> + allow_reachable_sha1_in_want = git_config_bool(var, value);
Using all lowercase is correct here, even though the "camelCase in
documentation and log message for humans" suggestion above still
stands.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html