Re: Improvement: `git-maintenance` to allow configuring of remotes to fetch

[Junio C Hamano <gitster@pobox.com>]

Patrick Steinhardt <ps@pks.im> writes:

> The prefetch refspec would be rewritten by git-maintenance(1) such that
> the destination part (the right-hand side of the refspec) is prefixed
> with `refs/prefetch/`, same as the fetch refspec would be changed in
> this way.
>
> An alternative would be to _not_ rewrite the prefetch refspec at all and
> thus allow the user to prefetch into arbitrary hierarchies. But I'm a
> bit worried that this might cause users to misconfigure prefetches by
> accident, causing it to overwrite their usual set of refs.

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.

As you too agree with the position to consider "prefetch" should be
invisible to the end-users, we should not allow users to specify the
full refspec at all, or if it is forced or not with "+" prefix.
Only accept a set of patterns to match, and keep it opaque where in
the local refs/* hierarchy they are stored.  It is an implementation
detail that the users should not have to know about and rely on.

Thanks.