git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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
Previous: Shubham KanodiaNext: Shubham Kanodia
Message 5 of 10 in “Improvement: `git-maintenance` to allow configuring of remotes to fetch”
  1. Shubham KanodiaAug 26, 2024
  2. Patrick SteinhardtAug 28, 2024
  3. Junio C HamanoAug 28, 2024
  4. Shubham KanodiaSep 2, 2024
  5. Patrick SteinhardtSep 3, 2024
  6. Shubham KanodiaSep 3, 2024
  7. Patrick SteinhardtSep 3, 2024
  8. Junio C HamanoSep 3, 2024
  9. Shubham KanodiaSep 4, 2024
  10. Shubham KanodiaSep 4, 2024

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.