git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Xing Xin via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org,  Brandon Williams <bmwill@google.com>,
	 Jonathan Tan <jonathantanmy@google.com>,
	 Patrick Steinhardt <ps@pks.im>,
	 Liu Zhongbo <liuzhongbo.6666@bytedance.com>,
	 blanet <bupt_xingxin@163.com>,
	Xing Xin <xingxin.xx@bytedance.com>
Subject: Re: [PATCH v3 4/5] fetch: respect --server-option when fetching multiple remotes
Date: Tue, 08 Oct 2024 10:57:13 -0700	[thread overview]
Message-ID: <xmqqv7y21nra.fsf@gitster.g> (raw)
In-Reply-To: <420b15d9f37d2510d0e4f5390a4b93a5ead7c966.1728358699.git.gitgitgadget@gmail.com> (Xing Xin via GitGitGadget's message of "Tue, 08 Oct 2024 03:38:18 +0000")

"Xing Xin via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: Xing Xin <xingxin.xx@bytedance.com>
>
> Fix an issue where server options specified via the command line
> (`--server-option` or `-o`) were not sent when fetching from multiple
> remotes using Git protocol v2.
>
> To reproduce the issue with a repository containing multiple remotes:
>
>   GIT_TRACE_PACKET=1 git -c protocol.version=2 fetch --server-option=demo --all
>
> Observe that no server options are sent to any remote.
>
> The root cause was identified in `builtin/fetch.c:fetch_multiple`, which
> is invoked when fetching from more than one remote. This function forks
> a `git-fetch` subprocess for each remote but did not include the
> specified server options in the subprocess arguments.
>
> This commit ensures that command-line specified server options are
> properly passed to each subprocess. Relevant tests have been added.

A more interesting use case, as there is no reason to expect that a
single server-option command line option may apply to all remotes,
would be to configure different server options for different remotes
via the new serverOption configuration, so that different server
options are used for different remotes.

If it happens that the same server option is applicable for all
remotes, it is reasonable to give --server-option from the command
line and expect it to be propagated down to subfetches, so
regardless of the "what happens when different remotes have
different options configured?" above, the change in this step looks
reasonable to me.

  reply	other threads:[~2024-10-08 17:57 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-02 12:13 [PATCH 0/4] Support server option from configuration blanet via GitGitGadget
2024-09-02 12:13 ` [PATCH 1/4] transport: add parse_transport_option() method Xing Xin via GitGitGadget
2024-09-02 12:13 ` [PATCH 2/4] builtin/fetch.c: add fetch.serverOption configuration Xing Xin via GitGitGadget
2024-09-03 10:09   ` Patrick Steinhardt
2024-09-02 12:13 ` [PATCH 3/4] builtin/clone.c: recognize " Xing Xin via GitGitGadget
2024-09-03 10:09   ` Patrick Steinhardt
2024-09-04  7:49     ` Xing Xin
2024-09-05 11:05       ` Patrick Steinhardt
2024-09-05 12:12         ` Xing Xin
2024-09-05 13:44           ` Patrick Steinhardt
2024-09-05 17:50             ` Junio C Hamano
2024-09-09  2:50             ` Re:Re: Re: " Xing Xin
2024-09-09 11:49               ` Patrick Steinhardt
2024-09-23 13:04                 ` Xing Xin
2024-09-09 15:44               ` Junio C Hamano
2024-09-02 12:13 ` [PATCH 4/4] builtin/ls-remote.c: " Xing Xin via GitGitGadget
2024-09-03 10:09   ` Patrick Steinhardt
2024-09-03 10:09 ` [PATCH 0/4] Support server option from configuration Patrick Steinhardt
2024-09-23 12:17 ` [PATCH v2 0/5] " blanet via GitGitGadget
2024-09-23 12:17   ` [PATCH v2 1/5] transport: introduce parse_transport_option() method Xing Xin via GitGitGadget
2024-09-23 12:17   ` [PATCH v2 2/5] remote: introduce remote.<name>.serverOption configuration Xing Xin via GitGitGadget
2024-10-07  8:22     ` Patrick Steinhardt
2024-10-08  3:38       ` Xing Xin
2024-09-23 12:17   ` [PATCH v2 3/5] transport.c::handshake: make use of server options from remote Xing Xin via GitGitGadget
2024-09-23 12:17   ` [PATCH v2 4/5] fetch: respect --server-option when fetching multiple remotes Xing Xin via GitGitGadget
2024-10-07  8:22     ` Patrick Steinhardt
2024-09-23 12:17   ` [PATCH v2 5/5] ls-remote: leakfix for not clearing server_options Xing Xin via GitGitGadget
2024-10-07  8:22     ` Patrick Steinhardt
2024-10-07  8:23   ` [PATCH v2 0/5] Support server option from configuration Patrick Steinhardt
2024-10-08  3:42     ` Xing Xin
2024-10-08  3:38   ` [PATCH v3 " blanet via GitGitGadget
2024-10-08  3:38     ` [PATCH v3 1/5] transport: introduce parse_transport_option() method Xing Xin via GitGitGadget
2024-10-08  3:38     ` [PATCH v3 2/5] remote: introduce remote.<name>.serverOption configuration Xing Xin via GitGitGadget
2024-10-08  3:38     ` [PATCH v3 3/5] transport.c::handshake: make use of server options from remote Xing Xin via GitGitGadget
2024-10-08  3:38     ` [PATCH v3 4/5] fetch: respect --server-option when fetching multiple remotes Xing Xin via GitGitGadget
2024-10-08 17:57       ` Junio C Hamano [this message]
2024-10-08  3:38     ` [PATCH v3 5/5] ls-remote: leakfix for not clearing server_options Xing Xin via GitGitGadget
2024-10-08  4:00     ` [PATCH v3 0/5] Support server option from configuration Patrick Steinhardt
2024-10-08 17:23       ` Junio C Hamano

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=xmqqv7y21nra.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=bmwill@google.com \
    --cc=bupt_xingxin@163.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=jonathantanmy@google.com \
    --cc=liuzhongbo.6666@bytedance.com \
    --cc=ps@pks.im \
    --cc=xingxin.xx@bytedance.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).