From: Junio C Hamano <gitster@pobox.com>
To: Tamino Bauknecht <dev@tb6.eu>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] fetch: add new config option fetch.all
Date: Thu, 04 Jan 2024 10:23:11 -0800 [thread overview]
Message-ID: <xmqqv8896jqo.fsf@gitster.g> (raw)
In-Reply-To: <20240104143656.615117-1-dev@tb6.eu> (Tamino Bauknecht's message of "Thu, 4 Jan 2024 15:33:55 +0100")
Tamino Bauknecht <dev@tb6.eu> writes:
> This commit introduces the new boolean configuration option fetch.all
> which allows to fetch all available remotes by default. The config
> option can be overridden by explicitly specifying a remote.
> The behavior for --all is unchanged and calling git-fetch with --all and
> a remote will still result in an error.
This sounds like a usability annoyance for forks that use --all some
of the time and not always, as they now have to remember not just to
pass something to countermand the configured fetch.all but what that
something exactly is (i.e., the name of the remote they fetch from
by default), which makes fetch.all less appealing. I wonder if we
can instead take "--no-all" from the command line to make configured
fetch.all ignored (hence, giving an explicit remote will fetch from
there, and not giving any remote will fetch from whereever the
command will fetch from with "git -c fetch.all=false fetch")?
> The option was also added to the config documentation and new tests
> cover the expected behavior.
> ---
Missing sign-off.
> Documentation/config/fetch.txt | 4 ++
> builtin/fetch.c | 18 +++++--
> t/t5514-fetch-multiple.sh | 88 ++++++++++++++++++++++++++++++++++
> 3 files changed, 105 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/config/fetch.txt b/Documentation/config/fetch.txt
> index aea5b97477..4f12433874 100644
> --- a/Documentation/config/fetch.txt
> +++ b/Documentation/config/fetch.txt
> @@ -50,6 +50,10 @@ fetch.pruneTags::
> refs. See also `remote.<name>.pruneTags` and the PRUNING
> section of linkgit:git-fetch[1].
>
> +fetch.all::
> + If true, fetch will attempt to update all available remotes.
> + This behavior can be overridden by explicitly specifying a remote.
And we should say that this configuration variable defaults to false.
> @@ -2337,11 +2344,12 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)
> fetch_bundle_uri(the_repository, bundle_uri, NULL))
> warning(_("failed to fetch bundles from '%s'"), bundle_uri);
>
> - if (all) {
> - if (argc == 1)
> - die(_("fetch --all does not take a repository argument"));
> - else if (argc > 1)
> - die(_("fetch --all does not make sense with refspecs"));
> + if (all && argc == 1) {
> + die(_("fetch --all does not take a repository argument"));
> + } else if (all && argc > 1) {
> + die(_("fetch --all does not make sense with refspecs"));
> + } else if (all || (config.all > 0 && argc == 0)) {
> + /* Only use fetch.all config option if no remotes were explicitly given */
> (void) for_each_remote(get_one_remote_for_fetch, &list);
This conditional cascade will probably need to change when we allow
"--no-all" to countermand the configured fetch.all anyway, so I
won't worry about it now, but it looks somewhat convoluted that we
have to re-check "all" many times, which was the point of the
original that implemented this as a nested conditional.
Thanks.
next prev parent reply other threads:[~2024-01-04 18:23 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-18 20:15 new config option "fetch.all" Tamino Bauknecht
2024-01-04 14:33 ` [PATCH] fetch: add new config option fetch.all Tamino Bauknecht
2024-01-04 17:33 ` Taylor Blau
2024-01-04 18:04 ` Eric Sunshine
2024-01-04 18:29 ` Junio C Hamano
2024-01-04 18:32 ` Tamino Bauknecht
2024-01-04 19:13 ` Taylor Blau
2024-01-04 18:23 ` Junio C Hamano [this message]
2024-01-04 20:18 ` Tamino Bauknecht
2024-01-04 20:49 ` Junio C Hamano
2024-01-04 20:25 ` Tamino Bauknecht
2024-01-04 20:50 ` Eric Sunshine
2024-01-04 20:55 ` Eric Sunshine
2024-01-04 22:22 ` [PATCH v2 1/2] " Tamino Bauknecht
2024-01-04 22:22 ` [PATCH v2 2/2] fetch: add cli option --default-only Tamino Bauknecht
2024-01-05 2:43 ` Eric Sunshine
2024-01-05 16:13 ` Junio C Hamano
2024-01-06 20:17 ` [PATCH v3] fetch: add new config option fetch.all Tamino Bauknecht
2024-01-06 23:32 ` Eric Sunshine
2024-01-06 23:37 ` Eric Sunshine
2024-01-08 17:25 ` Junio C Hamano
2024-01-08 21:13 ` [PATCH] " Tamino Bauknecht
2024-01-05 1:02 ` [PATCH v2 1/2] " Eric Sunshine
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=xmqqv8896jqo.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=dev@tb6.eu \
--cc=git@vger.kernel.org \
/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).