From: Derrick Stolee <stolee@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Shubham Kanodia via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, "Patrick Steinhardt [ ]" <ps@pks.im>,
Shubham Kanodia <shubham.kanodia10@gmail.com>
Subject: Re: [PATCH] remote: prefetch config
Date: Wed, 4 Sep 2024 22:08:44 -0400 [thread overview]
Message-ID: <52f6da10-e39a-4a2d-bd9a-5739a49235c2@gmail.com> (raw)
In-Reply-To: <xmqqfrqf87gb.fsf@gitster.g>
On 9/4/24 4:55 PM, Junio C Hamano wrote:
> Derrick Stolee <stolee@gmail.com> writes:
>>> + # Run maintenance prefetch task
>>> + GIT_TRACE2_EVENT="$(pwd)/prefetch.txt" git maintenance run --task=prefetch 2>/dev/null &&
>>> +
>>> + # Check that remote1 was not fetched (prefetch=false)
>>> + test_subcommand ! git fetch remote1 --prefetch --prune --no-tags \
>>> + --no-write-fetch-head --recurse-submodules=no --quiet \
>>> + <prefetch.txt &&
>>
>> I'm happy to see this use of test_subcommand to validate the behavior
>> of this patch!
>
> I found it a bit disturbing that the pattern is overly specific.
>
> The only thing we are interested in is that we are not fetching from
> remote1, so it _should_ suffice if we could write
>
> test_subcommand ! git fetch remote1 <prefetch.txt &&
>
> to avoid being tied to how the current version of Git happens to
> pass these command line option flags and the order it does so.
>
> Looking at the implementation of test_subcommand, it seems that we
> cannot quite do that (it assumes that the pattern it assembles out
> of the parameters are to match the full argument list used in
> invocation, enclosing them in a single [] pair and without giving
> the caller an easy way to sneak wildcards like ".*" in), which is
> sad.
I agree the ergonomics of the test_subcommand helper is a bit poor
(and not this patch author's fault). The trickiest part is the
negative case, as in this highlighted one. It's hard to read from
this if the subcommand wasn't found because the argument list is
too specific and doesn't match the exact arguments.
It helps that the same options are given for the other, positive
tests. But maybe that could be a hint as to how to make this test
a bit cleaner: make a variable describing the "uninteresting"
arguments. Something like...
args="--prefetch --prune --no-tags \
--no-write-fetch-head --recurse-submodules=no --quiet" &&
test_subcommand ! git fetch remote1 $args <prefetch.txt &&
test_subcommand git fetch remote2 $args <prefetch.txt &&
test_subcommand git fetch remote3 $args <prefetch.txt &&
Thanks,
-Stolee
next prev parent reply other threads:[~2024-09-05 2:08 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-04 17:59 [PATCH] remote: prefetch config Shubham Kanodia via GitGitGadget
2024-09-04 20:03 ` Derrick Stolee
2024-09-04 20:55 ` Junio C Hamano
2024-09-05 2:08 ` Derrick Stolee [this message]
2024-09-05 2:51 ` Shubham Kanodia
2024-09-05 15:00 ` Junio C Hamano
2024-09-05 2:52 ` [PATCH v2] " Shubham Kanodia via GitGitGadget
2024-09-05 16:06 ` Junio C Hamano
2024-09-05 16:43 ` Shubham Kanodia
2024-09-05 16:52 ` Junio C Hamano
2024-09-05 17:19 ` Shubham Kanodia
2024-09-05 17:54 ` Junio C Hamano
2024-09-05 16:45 ` [PATCH v3] " Shubham Kanodia via GitGitGadget
2024-09-05 19:43 ` [PATCH v4] " Shubham Kanodia via GitGitGadget
2024-09-05 20:57 ` Junio C Hamano
2024-09-06 9:42 ` Shubham Kanodia
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52f6da10-e39a-4a2d-bd9a-5739a49235c2@gmail.com \
--to=stolee@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
--cc=ps@pks.im \
--cc=shubham.kanodia10@gmail.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.
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 NNTP newsgroup(s).