Re: [PATCH v2] upload-pack: Optionally allow fetching reachable sha1
flat view
From: Junio C Hamano <hidden>
Date: 2016-06-15 23:04:39
Fredrik Medley [off-list ref] 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 <redacted> ---
Much easier to read and understand.
quoted hunk
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.
quoted hunk
+ 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/
quoted hunk
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.
quoted hunk
@@ -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.