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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Sep 3, 2024 at 9:37 PM Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> Patrick Steinhardt <ps@xxxxxx> writes:
>
> > 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.
>
> I agree that it is the right place to configure this as attributes
> to remotes.  It would make it handy if we could give a catch-all
> configuration, though.  For example:
>
>  [remote "origin"]
>         prefetch = true
>         prefetchref = refs/heads/* refs/tags/*
>  [remote "*"]
>         prefetch = false
>
> may toggle prefetch off for all remotes, except that the tags and
> the local branches of the remote "origin" are prefetched.  Instead
> of a multi-value configuration variable (like remote.*.fetch) where
> we need to worry about clearing convention, we can use a regular
> "last one wins" variable that is whitespace separated patterns, as
> such a pattern can never have a whitespace in it.
>
> As you too agree with the position to consider "prefetch" should be
> invisible to the end-users, we should not allow users to specify the
> full refspec at all, or if it is forced or not with "+" prefix.
> Only accept a set of patterns to match, and keep it opaque where in
> the local refs/* hierarchy they are stored.  It is an implementation
> detail that the users should not have to know about and rely on.
>
> Thanks.

Right so I have good direction to start working on this. I'm going to
tackle this in a few parts since this is my first contribution —

1. adding a boolean `prefetch` attribute to `remote` — allows control
over remotes that prefetch
2. adding `prefetchref` — allows control over refs per remote.
3. Check if adding a ` [remote "*"]` catchall is a possibility

For the boolean `prefetch` value the —
1. The default would be assumed to be `true`
2. No changes in behavior to any variation of  `git fetch --prefetch`
command itself.
If no remote is supplied to `git fetch` then it means default remote,
or if `--all` is used, it means all remotes and `--prefetch` for both
always
prefetches irrespective of the config value.

If I understand the codebase well, the changes would primarily affect
`remote.c` and `gc.c`.

Also much thanks for the feedback both of you've given thus far.





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux