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

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