Jeff Hostetler <git@xxxxxxxxxxxxxxxxx> writes:
> On 7/15/22 1:29 PM, Jonathan Tan wrote:
>> Administrators of a managed Git environment (like the one at $DAYJOB)
>> might want to quantify the performance change of fetches with and
>> without partial clone from the client's point of view. Therefore, log
>> the effective filter being sent to the server whenever a fetch (or
>> clone) occurs. Note that this is not necessarily the same as what's
>> specified on the CLI, because during a fetch, the configured filter is
>> used whenever a filter is not specified on the CLI.
>> This is implemented for protocol v0, v1, and v2.
Is that different to say "for all protocols"? I am wondering if it
is worth saying (unlike in a hypothetical case where we do not
support v0 and v1 we may want to state why we only support v2).
>> Signed-off-by: Jonathan Tan <jonathantanmy@xxxxxxxxxx>
>> ---
>> fetch-pack.c | 10 ++++++++--
>> 1 file changed, 8 insertions(+), 2 deletions(-)
>> diff --git a/fetch-pack.c b/fetch-pack.c
>> index cb6647d657..dec8743bec 100644
>> --- a/fetch-pack.c
>> +++ b/fetch-pack.c
>> @@ -392,7 +392,10 @@ static int find_common(struct fetch_negotiator *negotiator,
>> if (server_supports_filtering && args->filter_options.choice) {
>> const char *spec =
>> expand_list_objects_filter_spec(&args->filter_options);
>> + trace2_data_string("fetch", the_repository, "fetch/effective-filter", spec);
>> packet_buf_write(&req_buf, "filter %s", spec);
>> + } else {
>> + trace2_data_string("fetch", the_repository, "fetch/effective-filter", "none");
Do we show "none" anywhere else where an expanded list objects
filter spec is expected?
I am wondering two things:
- The lack of this line would be a cleaner implementation of a
signal to say "this client did not ask any filtering".
- It would be good if we keep what report here more-or-less the
same as what we can pass "--filter=" on the command line of
"git pack-objects".
If "--filter=none" meant "this --filter passes everything", then
saying "none" here makes perfect sense wrt the latter, but I doubt
it is the case.
>> }
>> packet_buf_flush(&req_buf);
>> state_len = req_buf.len;
>> @@ -1328,9 +1331,12 @@ static int send_fetch_request(struct fetch_negotiator *negotiator, int fd_out,
>> const char *spec =
>> expand_list_objects_filter_spec(&args->filter_options);
>> print_verbose(args, _("Server supports filter"));
>> + trace2_data_string("fetch", the_repository, "fetch/effective-filter", spec);
>> packet_buf_write(&req_buf, "filter %s", spec);
>> - } else if (args->filter_options.choice) {
>> - warning("filtering not recognized by server, ignoring");
>> + } else {
>> + if (args->filter_options.choice)
>> + warning("filtering not recognized by server, ignoring");
>> + trace2_data_string("fetch", the_repository, "fetch/effective-filter", "none");
At the first glance, this seems to lose data, because you should be
able to use expand_list_objects_filter_spec() to report the filter
spec. But this is reporting the filter that was actually in effect,
so it is OK.
But the same question about "none" remains.
>> }
>> if (server_supports_feature("fetch", "packfile-uris", 0)) {
>>
>
> This looks nice. Thanks!
> Jeff
Will queue with your Acked-by, then?
Thanks, both.
