On Tue, Nov 05, 2024 at 04:39:06PM -0800, Junio C Hamano wrote: > Shubham Kanodia <shubham.kanodia10@xxxxxxxxx> 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. Ah, I missed your mail here. I replied to this bit in a parallel email. > 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? I wouldn't say unworkable, but it certainly isn't as easy as just adding the new syntax. > 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. So yes, we'd have to teach Git to ignore "*" remotes in many places. I would hope that it isn't all that involved and that we only need to adjust a couple of places to ignore "*". But the remote logic is somewhat outside of my area of expertise, so my hope might be misplaced. If so, we might think about using a different syntax to achieve the same thing. Patrick
