> Patrick Steinhardt <ps@xxxxxx> writes:
>
> > I'm not aware of any discussion around this...
>
> I do not think so, either.
>
> I agree that it makes as much sense to limit prefetches to a subset
> of remotes as it makes sense to limit to certain hierarchies (e.g.
> excluding refs/changes/ or even limiting to refs/heads/seen and
> nothing else).
I'm seeking advice on the configuration option structure for this
feature. The typical config format for maintenance tasks seems to be
as follows:
`maintenance.<task-name>.<option>`
A natural extension of this for the prefetch task could be:
```
git config maintenance.prefetch.<remote-name>.refs refs/heads/master
```
In this structure, the 'refs' value represents only the source part of
a refspec, and both remote and refs can be configured.
Specifying a full refspec isn't necessary since the --prefetch option
may override the destination anyway.
While I've successfully implemented this approach, I'm open to
suggestions for alternative configuration options. My concerns are:
1. Most Git configurations are nested up to three levels deep, whereas
this proposal introduces a fourth level.
2. This configuration appears in the config file as:
```
[maintenance "prefetch.origin"]
refs = refs/heads/master
```
which might look odd?
Also, hopefully my mail is formatted better this time!
