Re: Improvement: `git-maintenance` to allow configuring of remotes to fetch
- From
Patrick Steinhardt <ps@pks.im>
- Date
- Sep 3, 2024, 05:18 UTC
- Message-ID
- <ZtacHCuql0pX3V2u@tanuki>
- In-Reply-To
- <CAG=Um+2OQofcfo3vjvPJEAUht5cGg0LnPAx54SWUPETgkRACPQ@mail.gmail.com>
On Mon, Sep 02, 2024 at 09:16:24PM +0530, Shubham Kanodia wrote:
Show 40 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?
Agreed, it does. To me, the most natural way to configure this would be as part of the remotes themselves:
```
[remote "origin"]
url = https://example.com/repo.git
fetch = +refs/heads/*:refs/remotes/origin/*
# Whether or not the prefetch task shall fatch this repository.
# Defaults to `true`.
prefetch = true
# An arbitrary number of refspecs used by the prefetch task.
# Overrides the fetch refspec if given, otherwise we fall back to
# using the fetch refspec.
prefetchRefspec = +refs/heads/main:refs/remotes/origin/main
```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.
> Also, hopefully my mail is formatted better this time!
It is, thanks!
Patrick