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

From: Shubham Kanodia <shubhamsizzles@gmail.com>
Date: Sep 2, 2024, 15:46 UTC
Message-ID: <CAG=Um+2OQofcfo3vjvPJEAUht5cGg0LnPAx54SWUPETgkRACPQ@mail.gmail.com>
In-Reply-To: <xmqq4j7438yc.fsf@gitster.g>

Show 10 quoted lines

> Patrick Steinhardt <ps@pks.im> 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!