Re: [PATCH 2/3] upload-pack: Prepare to extend allow-tip-sha1-in-want
- From
Fredrik Medley <fredrik.medley@gmail.com>
- Date
- May 19, 2015, 20:19 UTC
- Message-ID
- <CABA5-zkLY9vnZnAffn7=NYOmaoXeK8LJiNBVmyvRmc803mfGVg@mail.gmail.com>
- In-Reply-To
- <xmqqmw19earu.fsf@gitster.dls.corp.google.com>
2015-05-12 23:39 GMT+02:00 Junio C Hamano <gitster@pobox.com>:
Show 42 quoted lines
> Fredrik Medley <fredrik.medley@gmail.com> writes:
>
>> Subject: Re: [PATCH 2/3] upload-pack: Prepare to extend allow-tip-sha1-in-want
>>
>> diff --git a/fetch-pack.c b/fetch-pack.c
>> index 48526aa..77174f9 100644
>> --- a/fetch-pack.c
>> +++ b/fetch-pack.c
>> @@ -43,7 +43,10 @@ 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 specifying sha1 if it is a ref tip. */
>> +#define ALLOW_TIP 01
>> +static int allow_request_with_bare_object_name;
>
> This side is OK, as "request" is by the end user giving the object
> name from its command line.
>
>> diff --git a/upload-pack.c b/upload-pack.c
>> index aa84576..708a502 100644
>> --- a/upload-pack.c
>> +++ b/upload-pack.c
>> @@ -35,7 +35,9 @@ static int multi_ack;
>> static int no_done;
>> static int use_thin_pack, use_ofs_delta, use_include_tag;
>> static int no_progress, daemon_mode;
>> -static int allow_tip_sha1_in_want;
>> +/* Allow specifying sha1 if it is a ref tip. */
>> +#define ALLOW_TIP 01
>> +static int allow_request_with_bare_object_name;
>
> This side is not quite good, as the request coming over wire is
> always 40-hex bare object name. We are allowing requests against
> what we did not advertise (either the tip of hidden refs, or
> somewhere deep in the history from some tip that may or may not have
> been advertised).
>
> allow-unadvertised-object-request or something, perhaps?
>My imagination is not any better, so I will stick with allow_unadvertised_object_request. I do think that that name fits okay in fetch-pack.c as well. The name will also allow for a possibly future option of requesting (unadvertised) hidden refs by name, but it would of course require larger changes of the protocol.