git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Phillip Wood <phillip.wood123@gmail.com>
To: Patrick Steinhardt <ps@pks.im>,
	Shubham Kanodia <shubham.kanodia10@gmail.com>
Cc: Shubham Kanodia via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
	Derrick Stolee <stolee@gmail.com>
Subject: Re: [PATCH v4] remote: allow specifying refs to prefetch
Date: Wed, 6 Nov 2024 11:04:48 +0000	[thread overview]
Message-ID: <43dd8960-4438-402e-ad45-973565a6860e@gmail.com> (raw)
In-Reply-To: <ZysQvUyxgdRqjvj2@pks.im>

On 06/11/2024 06:46, Patrick Steinhardt wrote:
> On Tue, Nov 05, 2024 at 09:56:52PM +0530, Shubham Kanodia wrote:
>>
>> Let me add context here based on a few things that have already been discussed
>> as a part of this thread or an earlier discussion on
>> https://lore.kernel.org/git/CAG=Um+1wTbXn_RN+LOCrpZpSNR_QF582PszxNyhz5anVHtBp+w@mail.gmail.com/
>>
>>> I'm coming rather late to the party and simply want to review this so
>>> that the thread gets revived. So my context may be lacking, please
>>> forgive me if I am reopening things that were already discussed.
>>
>> 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/—
> 
> Fair enough, thanks for the pointer! The reason stated by Junio is that
> having a space-separated list of refspecs makes it easier to reset the
> refspec again, as we can simply use a "last-one-wins" pattern. And while
> I understand that, I would claim that we already have a properly
> established way to reset multi-valued lists by first assigning an empty
> value:
> 
>      [remote "origin"]
>          prefetchref = refs/heads/*
>          prefetchref = refs/tags/*
>          prefetchref =
>          prefetchref = refs/heads/*
> 
> The final value would be only "refs/heads/*" due to the reset.
> 
> So overall I'm still leaning into the direction of making this a
> multi-valued list for the sake of consistency with other refspec
> configs. @Junio Let me know in case you disagree though.

It is also easier to manipulate the list with "git config" when it is 
multivalued as one can add values and "git config --add" and remove 
specific entries with "git config --unset <key> <pattern>". With a 
single entry to append a new value one has to resort to something like

	git config <key> "$(echo $(git config <key>) <new-value>)"

which is not very user friendly. Deleting a value is even less friendly.

Best Wishes

Phillip


  reply	other threads:[~2024-11-06 11:04 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
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 [this message]
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=43dd8960-4438-402e-ad45-973565a6860e@gmail.com \
    --to=phillip.wood123@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=phillip.wood@dunelm.org.uk \
    --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).