Re: [PATCH v2] upload-pack: Optionally allow fetching reachable sha1

2015-05-06 0:16 GMT+02:00 Junio C Hamano [off-list ref]:

Fredrik Medley [off-list ref] writes:

quoted

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.

I would prefer using allowReachableSha1InWant. Please tell
me if I should use SHA1InWant instead of Sha1InWant.
(I cannot find anything similar in the repository.)

quoted

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.

I think the reasoning is sensible and I can see a possibility to allow
non-reachable SHA1 in the future, even I would very much recommend
against the use of such option for security reasons.

What I can understand, the capability protocol will still need both options
as separate variables. (I forgot to update the technical documentation
before will do that as well.)

Thank you all for quick replies.