From: Shubham Kanodia <shubhamsizzles@gmail.com>
Date: Mon, 02 Sep 2024 15:46:24 GMT
Subject: Re: Improvement: `git-maintenance` to allow configuring of remotes to fetch
Message-ID: <CAG=Um+2OQofcfo3vjvPJEAUht5cGg0LnPAx54SWUPETgkRACPQ@mail.gmail.com>
In-Reply-To: <xmqq4j7438yc.fsf@gitster.g>

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