2015-05-06 0:16 GMT+02:00 Junio C Hamano <gitster@xxxxxxxxx>:
> Fredrik Medley <fredrik.medley@xxxxxxxxx> writes:
>>
>> 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.)
>
>> 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.
--
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