Re: [PATCH v4] remote: allow specifying refs to prefetch

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 6, 2024, 00:39 UTC
Message-ID: <xmqqy11xqjpx.fsf@gitster.g>
In-Reply-To: <CAG=Um+3D3iGPRv4t4DcCP=Bh7gbAQ6cSJ79jmg2h-qbSiQRkUA@mail.gmail.com>

Shubham Kanodia <shubham.kanodia10@gmail.com> writes:

Show 21 quoted lines

> 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.