git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Alex Riesen <alexander.riesen@cetitec.com>
Cc: git@vger.kernel.org, Jeff King <peff@peff.net>,
	Eric Wong <normalperson@yhbt.net>
Subject: Re: [PATCH] config: option transfer.ipversion to set transport protocol version for network fetches
Date: Fri, 18 Sep 2020 09:37:30 -0700	[thread overview]
Message-ID: <xmqq363fnir9.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <20200918071647.GA17896@pflmari> (Alex Riesen's message of "Fri, 18 Sep 2020 09:16:47 +0200")

Alex Riesen <alexander.riesen@cetitec.com> writes:

>     git fetch --ipversions=ipv6,ipv8
>
> Given multiple times, the last option wins, as usual:

Just a clarification on "the last option wins".

You do not mean "I said v6 earlier but no, I want v8", with the
above.  What you mean is that

>
>     $ cat my-fetch
>     #!/bin/sh
>     git fetch --ipversions=ipv4 "$@"
>
>     $ ./my-fetch --ipversions=all

the argument given to 'my-fetch' overrides what is hardcoded in
'my-fetch', i.e. "I said v4, but I take it back; I want to accept
any".

I find the above sensible.

> BTW, transport.c already converts transport->family to bit-flags in
> connect_setup.

Yes, that is why I suggested the "list of acceptable choices"
approach as a direction to go in the future, primarily to limit the
scope of this current work.  I do not mind it if you want to bite
the whole piece right now, though.

By the way, I have a mild preference to call the option after the
phrase "protocol-family", without "IP", so that we won't be limited
to Internet protocols.  IOW, --ipversions is a bad name for the new
commnad line option in my mind.

As I said elsewhere, I also think TRANSPORT_FAMILY_ALL is a
misnomer.  When it is specified, we don't use all the available ones
at the same time.  What it says is that we accept use of any
protocol families that are supported.  It is OK to use ALL in the
CPP macro as it is merely an internal implementation detail, but if
we are going to expose it to end users as one of the choices, I'd
prefer to use 'any', and not 'all', as the value for the new command
line option.

Thanks.

  reply	other threads:[~2020-09-18 16:37 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-14 12:19 sub-fetches discard --ipv4|6 option Alex Riesen
2020-09-14 19:49 ` Jeff King
2020-09-15 11:50   ` Alex Riesen
2020-09-15 11:54     ` [PATCH] Pass --ipv4 and --ipv6 options to sub-fetches when fetching multiple remotes and submodules Alex Riesen
2020-09-15 13:06       ` Jeff King
2020-09-16  4:17         ` Junio C Hamano
2020-09-16  7:27           ` Alex Riesen
2020-09-15 21:19       ` Junio C Hamano
2020-09-16  7:25         ` Alex Riesen
2020-09-15 13:05     ` sub-fetches discard --ipv4|6 option Jeff King
2020-09-15 13:54       ` [PATCH] config: option transfer.ipversion to set transport protocol version for network fetches Alex Riesen
2020-09-16 20:02         ` Jeff King
2020-09-17  8:07           ` Alex Riesen
2020-09-17 13:20           ` [PATCH] Config option to set the " Alex Riesen
2020-09-17 13:26             ` Alex Riesen
2020-09-17 13:31             ` Jeff King
2020-09-17 13:35               ` Alex Riesen
2020-09-17 14:51                 ` Jeff King
2020-09-17 15:17                   ` Alex Riesen
2020-12-22 19:55                     ` Junio C Hamano
2021-01-07 10:06                       ` Alex Riesen
2020-09-17 16:05             ` Alex Riesen
2020-09-16 20:14         ` [PATCH] config: option transfer.ipversion to set " Junio C Hamano
2020-09-16 20:18           ` Jeff King
2020-09-16 22:50             ` Junio C Hamano
2020-09-16 22:52               ` Junio C Hamano
2020-09-17  0:48                 ` Jeff King
2020-09-17  0:57                   ` Junio C Hamano
2020-09-16 21:35           ` Junio C Hamano
2020-09-17 14:02             ` Alex Riesen
2020-09-17 22:31               ` Junio C Hamano
2020-09-18  7:16                 ` Alex Riesen
2020-09-18 16:37                   ` Junio C Hamano [this message]
2020-09-21 16:39                     ` Alex Riesen
2020-09-22  5:03                       ` Jeff King
2020-09-17  8:04           ` Alex Riesen
2020-09-17  8:18           ` Alex Riesen
2020-09-15 14:06       ` sub-fetches discard --ipv4|6 option Alex Riesen
2020-09-15 15:27         ` Jeff King
2020-09-15 16:03           ` Alex Riesen
2020-09-16 16:32             ` Jeff King
2020-09-17 14:33               ` Alex Riesen
2020-09-22  5:08                 ` Jeff King
2020-09-15 20:09           ` Junio C Hamano
2020-09-15 21:23             ` Jeff King
2020-09-15 21:32               ` Junio C Hamano
2020-09-16 16:34                 ` Jeff King
2020-09-16 21:20                   ` Junio C Hamano
2020-09-14 20:06 ` 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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqq363fnir9.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=alexander.riesen@cetitec.com \
    --cc=git@vger.kernel.org \
    --cc=normalperson@yhbt.net \
    --cc=peff@peff.net \
    --subject='Re: [PATCH] config: option transfer.ipversion to set transport protocol version for network fetches' \
    /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

Code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).