From: Junio C Hamano <gitster@pobox.com>
To: Shubham Kanodia <shubham.kanodia10@gmail.com>
Cc: Shubham Kanodia via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, "Patrick Steinhardt [ ]" <ps@pks.im>,
"Derrick Stolee [ ]" <stolee@gmail.com>
Subject: Re: [PATCH] remote: introduce config to set prefetch refs
Date: Mon, 09 Sep 2024 11:33:55 -0700 [thread overview]
Message-ID: <xmqq5xr4r818.fsf@gitster.g> (raw)
In-Reply-To: <CAG=Um+0GvFzdAZrCgoS52xh9DF2pntQ+7i+vqYMFQf-MWr3H5A@mail.gmail.com> (Shubham Kanodia's message of "Mon, 9 Sep 2024 23:51:39 +0530")
Shubham Kanodia <shubham.kanodia10@gmail.com> writes:
> How should we handle the related `remote.<remote-name>.fetch` config?
The get_ref_map() helper is what the rest of the code interacts with
configured refspec. remote->fetch is handled there and goes through
the same filter_prefetch_refspec().
> In an earlier discussion, it was discussed that —
> `.prefetchref` should override `.fetch` completely (instead of
> patching it) which makes sense to me.
Maybe it made sense to you back when it was discussed, but after
seeing the current code (before applying this patch), specifically
what happens in filter_prefetch_refspec(), it no longer makes much
sense to me.
Especially it is nonsense to allow .prefetchref to widen the set of
refs that are being prefetched beyond what is normally fetched, so
we should look at a design that easily allows such a configuration
with strong suspicion, I would think.
next prev parent reply other threads:[~2024-09-09 18:33 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-09 9:47 [PATCH] remote: introduce config to set prefetch refs Shubham Kanodia via GitGitGadget
2024-09-09 9:51 ` Shubham Kanodia
2024-09-09 16:42 ` Junio C Hamano
2024-09-09 18:21 ` Shubham Kanodia
2024-09-09 18:33 ` Junio C Hamano [this message]
2024-09-13 6:16 ` Shubham Kanodia
2024-09-13 16:58 ` Junio C Hamano
2024-09-14 19:35 ` Shubham Kanodia
2024-09-14 20:11 ` Junio C Hamano
2024-09-15 14:06 ` Shubham Kanodia
2024-09-15 16:12 ` Junio C Hamano
2024-09-16 4:34 ` Shubham Kanodia
2024-09-15 14:08 ` [PATCH v2] " Shubham Kanodia via GitGitGadget
2024-09-19 10:23 ` [PATCH v3] " Shubham Kanodia via GitGitGadget
2024-09-23 21:24 ` Junio C Hamano
2024-10-07 14:30 ` Shubham Kanodia
2024-10-04 20:21 ` [PATCH v4] remote: allow specifying refs to prefetch Shubham Kanodia via GitGitGadget
2024-11-04 8:47 ` Shubham Kanodia
2024-11-05 6:45 ` Patrick Steinhardt
2024-11-05 14:47 ` Phillip Wood
2024-11-05 16:26 ` Shubham Kanodia
2024-11-06 0:39 ` Junio C Hamano
2024-11-06 6:52 ` Patrick Steinhardt
2024-11-06 8:20 ` Junio C Hamano
2024-11-06 6:46 ` Patrick Steinhardt
2024-11-06 11:04 ` Phillip Wood
2024-11-05 14:45 ` Phillip Wood
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=xmqq5xr4r818.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=ps@pks.im \
--cc=shubham.kanodia10@gmail.com \
--cc=stolee@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).