From: Patrick Steinhardt <ps@pks.im>
To: Shubham Kanodia <shubhamsizzles@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: Improvement: `git-maintenance` to allow configuring of remotes to fetch
Date: Tue, 3 Sep 2024 07:18:20 +0200 [thread overview]
Message-ID: <ZtacHCuql0pX3V2u@tanuki> (raw)
In-Reply-To: <CAG=Um+2OQofcfo3vjvPJEAUht5cGg0LnPAx54SWUPETgkRACPQ@mail.gmail.com>
On Mon, Sep 02, 2024 at 09:16:24PM +0530, Shubham Kanodia wrote:
> > 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
next prev parent reply other threads:[~2024-09-03 5:18 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-26 11:50 Improvement: `git-maintenance` to allow configuring of remotes to fetch Shubham Kanodia
2024-08-28 11:32 ` Patrick Steinhardt
2024-08-28 16:31 ` Junio C Hamano
2024-09-02 15:46 ` Shubham Kanodia
2024-09-03 5:18 ` Patrick Steinhardt [this message]
2024-09-03 6:01 ` Shubham Kanodia
2024-09-03 9:48 ` Patrick Steinhardt
2024-09-03 16:07 ` Junio C Hamano
2024-09-04 16:29 ` Shubham Kanodia
2024-09-04 18:10 ` Shubham Kanodia
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZtacHCuql0pX3V2u@tanuki \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=shubhamsizzles@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).