On Sat, Sep 7, 2024 at 10:12 PM Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> Phillip Wood <phillip.wood123@xxxxxxxxx> writes:
>
> > Hi Junio and Shubham
> >
> > On 07/09/2024 06:41, Junio C Hamano wrote:
> >> Will merge to 'next'?
> >> - sk/enable-prefetch-per-remote 09-05 #1
> >> <pull.1779.v4.git.1725565398681.gitgitgadget@xxxxxxxxx>
> >
> > I've just taken a look at this and I'm left wondering why one would
> > want to skip prefetching from a remote but still fetch from it with
> > "git fetch --all". I set remote.<remote>.skipFetchAll for the remotes
> > I don't want to prefetch.
>
> It is nice to see a review from somebody who fetches from multiple
> remotes in real life. Very much appreciated. I have a few
> repositories to pull from, but I never do "fetch --all", so
> skipFetchAll was totally outside my awareness.
>
> > We also have remote.<remote>.skipDefaultUpdate I don't know
> > offhand if that prevents a remote from being prefetched as well.
>
> Yuck. And this one is described with an identical text as the
> previous one. What is going on?
>
> ... goes and looks ...
>
> Ah, yes, they internally update the same .skip_default_update member
> in the struct remote; the only bug is that the documentation does
> not make it clear that they are synonyms to each other.
>
> What is curious is that 7cc91a2f (Add the configuration option
> skipFetchAll, 2009-11-09) added for the sole purpose of adding this
> one, without explaining anything about the reason why it was needed,
> and my quick browsing did not find any discussion on the topic in
> the era.
>
> In any case, a remote that has .skip_default_update member set
> indeed is exempt from prefetch since 32f67888 (maintenance: respect
> remote.*.skipFetchAll, 2021-04-16), so it is a viable alternative
> (assuming that nobody would want to omit prefetching from a remote
> even if they want to fetch from the remote with "fetch --all" or
> "remote update", which is a sensible assumption) to just document
> this existing behaviour to help the users.
>
> > I think being able to specify which refs are prefectched would be
> > useful.
>
> Yes, that is what we said it is OK to punt in the first step, which
> is fine to be done in the follow-up step.
>
> --- >8 ---
> Subject: doc: remote.*.skip{DefaultUpdate,FetchAll} stops prefetch
>
> Back when 7cc91a2f (Add the configuration option skipFetchAll,
> 2009-11-09) added for the sole purpose of adding skipFetchAll as a
> synonym to skipDefaultUpdate, there was no explanation about the
> reason why it was needed., but these two configuration variables
> mean exactly the same thing.
>
> Also, when we taught the "prefetch" task to "git maintenance" later,
> we did make it pay attention to the setting, but we forgot to
> document it.
>
> Document these variables as synonyms that collectively implements
> the last-one-wins semantics, and also clarify that the prefetch task
> is also controlled by this variable.
>
> Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>
> ---
> * Note that "skipped by default" in the original has been rewritten
> to "skipped" (unconditional), and this is deliberate. When there
> is no conditionality and the behaviour is the only available one,
> it is *not* "by default".
>
> Documentation/config/remote.txt | 13 +++++++------
> Documentation/git-maintenance.txt | 3 +++
> 2 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git c/Documentation/config/remote.txt w/Documentation/config/remote.txt
> index 8efc53e836..36e771556c 100644
> --- c/Documentation/config/remote.txt
> +++ w/Documentation/config/remote.txt
> @@ -42,14 +42,15 @@ remote.<name>.mirror::
> as if the `--mirror` option was given on the command line.
>
> remote.<name>.skipDefaultUpdate::
> - If true, this remote will be skipped by default when updating
> - using linkgit:git-fetch[1] or the `update` subcommand of
> - linkgit:git-remote[1].
> + A deprecated synonym to `remote.<name>.skipFetchAll` (if
> + both are set in the configuration files with different
> + values, the value of the last occurrence will be used).
>
> remote.<name>.skipFetchAll::
> - If true, this remote will be skipped by default when updating
> - using linkgit:git-fetch[1] or the `update` subcommand of
> - linkgit:git-remote[1].
> + If true, this remote will be skipped when updating
> + using linkgit:git-fetch[1], the `update` subcommand of
> + linkgit:git-remote[1], and ignored by the prefetch task
> + of `git maitenance`.
>
> remote.<name>.receivepack::
> The default program to execute on the remote side when pushing. See
> diff --git c/Documentation/git-maintenance.txt w/Documentation/git-maintenance.txt
> index 51d0f7e94b..9d96819133 100644
> --- c/Documentation/git-maintenance.txt
> +++ w/Documentation/git-maintenance.txt
> @@ -107,6 +107,9 @@ with the prefetch task, the objects necessary to complete a later real fetch
> would already be obtained, making the real fetch faster. In the ideal case,
> it will just become an update to a bunch of remote-tracking branches without
> any object transfer.
> ++
> +The `remote.<name>.skipFetchAll` configuration can be used to
> +exclude a particular remote from getting prefetched.
>
> gc::
> Clean up unnecessary files and optimize the local repository. "GC"
I agree — there are rarely reasons to keep a different fetch behavior
for prefetch vs. fetch all, and `skipFetchAll` should
do the trick for most use cases. My original goal was to restrict refs
anyway, I don't work with multiple remotes either.
I'd have perhaps expected these properties to be documented (or at
least referenced) in the documentation for `git-fetch`.
The only place `skipFetchAll` is currently documented is in this large
master list of configs that are easy to miss —
https://git-scm.com/docs/git-config.
If there's a consensus, I'll switch to submitting a patch for
`prefetchref` instead.
`
