Re: [PATCH v3 4/5] fetch: respect --server-option when fetching multiple remotes

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

 



"Xing Xin via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:

> From: Xing Xin <xingxin.xx@xxxxxxxxxxxxx>
>
> 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.




[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