From: Junio C Hamano <gitster@pobox.com>
To: Shubham Kanodia <shubham.kanodia10@gmail.com>
Cc: Phillip Wood <phillip.wood123@gmail.com>,
Patrick Steinhardt <ps@pks.im>,
Shubham Kanodia via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, Derrick Stolee <stolee@gmail.com>
Subject: Re: [PATCH v4] remote: allow specifying refs to prefetch
Date: Tue, 05 Nov 2024 16:39:06 -0800 [thread overview]
Message-ID: <xmqqy11xqjpx.fsf@gitster.g> (raw)
In-Reply-To: <CAG=Um+3D3iGPRv4t4DcCP=Bh7gbAQ6cSJ79jmg2h-qbSiQRkUA@mail.gmail.com> (Shubham Kanodia's message of "Tue, 5 Nov 2024 21:56:52 +0530")
Shubham Kanodia <shubham.kanodia10@gmail.com> writes:
> I don't have a particular preference here, and this was discussed in
> an earlier thread
> where Junio opined (https://lore.kernel.org/git/xmqq5xrcn2k1.fsf@gitster.g/—
>
>> I agree that it is the right place to configure this as attributes
>> to remotes. It would make it handy if we could give a catch-all
>> configuration, though. For example:
>>
>> [remote "origin"]
>> prefetch = true
>> prefetchref = refs/heads/* refs/tags/*
>> [remote "*"]
>> prefetch = false
>>
>> may toggle prefetch off for all remotes, except that the tags and
>> the local branches of the remote "origin" are prefetched. Instead
>> of a multi-value configuration variable (like remote.*.fetch) where
>> we need to worry about clearing convention, we can use a regular
>> "last one wins" variable that is whitespace separated patterns, as
>> such a pattern can never have a whitespace in it.
> which is what my implementation is based on.
I am fine with space separated list or multi-valued variable. The
only difference is that with multi-valued list, we'd need to worry
about ensuring that we have a way to "clear" the values we have seen
so far. It has plenty of precedence and is not a rocket science.
The above, if I recall correctly, was solely about the need for
"catch-all default" (aka "*" remote) and not about multi-value vs
space separated last-one-wins value at all. IOW, the above could
have been
[remote "origin"]
prefetch = true
prefetchref = refs/heads/*
prefetchref = refs/tags/*
[remote "*"]
prefetch = false
and conveyed exactly what I wanted to say in the message you quoted.
In any case, I somehow thought that we discarded the arrangement
with "*" wildcard as unworkable. If I remember the discussion
before I left correctly, didn't it turn out to be troublesome to
have [remote "*"] section because existing code would need to
enumerate configured remotes, and we do not want to see "*" listed?
If we found a workable solution to that while I was away, that would
be great, but I haven't looked at what this latest round of the
series does to solve it (yet). Perhaps teaching "git remote" and
"git fetch --all" to skip "*" while enumerating remotes was
sufficient? I dunno.
Thanks.
next prev parent reply other threads:[~2024-11-06 0:39 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
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 [this message]
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=xmqqy11xqjpx.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=phillip.wood123@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.