From: Junio C Hamano <gitster@pobox.com>
To: Jeff Hostetler <git@jeffhostetler.com>
Cc: Jonathan Tan <jonathantanmy@google.com>, git@vger.kernel.org
Subject: Re: [PATCH] fetch-pack: write effective filter to trace2
Date: Fri, 15 Jul 2022 11:28:22 -0700 [thread overview]
Message-ID: <xmqqmtdaz0vt.fsf@gitster.g> (raw)
In-Reply-To: <770e3c15-90ea-7d6c-4854-608c0ad8cbaa@jeffhostetler.com> (Jeff Hostetler's message of "Fri, 15 Jul 2022 13:38:42 -0400")
Jeff Hostetler <git@jeffhostetler.com> 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@google.com>
>> ---
>> 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.
next prev parent reply other threads:[~2022-07-15 18:28 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-15 17:29 [PATCH] fetch-pack: write effective filter to trace2 Jonathan Tan
2022-07-15 17:38 ` Jeff Hostetler
2022-07-15 18:28 ` Junio C Hamano [this message]
2022-07-15 19:09 ` Jonathan Tan
2022-07-15 20:10 ` Junio C Hamano
2022-07-15 20:49 ` Jonathan Tan
2022-07-18 14:08 ` Jeff Hostetler
2022-07-18 15:53 ` Junio C Hamano
2022-07-18 16:18 ` Jonathan Tan
2022-07-18 17:56 ` Junio C Hamano
2022-07-18 17:00 ` [PATCH v2] " Jonathan Tan
2022-07-18 19:47 ` Junio C Hamano
2022-07-25 18:56 ` Junio C Hamano
2022-07-26 16:28 ` Jonathan Tan
2022-07-26 16:27 ` [PATCH v3] " Jonathan Tan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqmtdaz0vt.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@jeffhostetler.com \
--cc=git@vger.kernel.org \
--cc=jonathantanmy@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).