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@xxxxxxxxxxxxxx/
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
