All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Wong <normalperson@yhbt.net>
To: "Torsten Bögershausen" <tboegi@web.de>
Cc: Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org, Jeff King <peff@peff.net>
Subject: Re: [PATCH 2/1] support -4 and -6 switches for remote operations
Date: Sun, 31 Jan 2016 00:01:44 +0000	[thread overview]
Message-ID: <20160131000144.GA10117@dcvr.yhbt.net> (raw)
In-Reply-To: <56AD4887.3070207@web.de>

Torsten Bögershausen <tboegi@web.de> wrote:
> On 2016-01-30 14.13, Eric Wong wrote:
> > The ssh(1) command has an equivalent switches which we may
> > pass when we run them.

> Should we mention that putty and tortoiseplink don't have these options ?
> At least in the commit message ?

Sure, will remember for v2 and document in the manpages.

Curious, do these ssh implementations throw out a meaningful error
message when given these options?

> > --- a/builtin/clone.c
> > +++ b/builtin/clone.c
> > @@ -47,6 +47,7 @@ static const char *real_git_dir;
> >  static char *option_upload_pack = "git-upload-pack";
> >  static int option_verbosity;
> >  static int option_progress = -1;
> > +static int ipv4, ipv6;
> Do we need 2 variables here ?

Yes, I'm not sure how else to use OPT_BOOL below...

> Or would
> int preferred_ip_version
> be better ?
> >  static struct string_list option_config;
> >  static struct string_list option_reference;
> >  static int option_dissociate;
> > @@ -92,6 +93,8 @@ static struct option builtin_clone_options[] = {
> >  		   N_("separate git dir from working tree")),
> >  	OPT_STRING_LIST('c', "config", &option_config, N_("key=value"),
> >  			N_("set config inside the new repository")),
> > +	OPT_BOOL('4', "ipv4", &ipv4, N_("resolve IPv4 addresses only")),
> > +	OPT_BOOL('6', "ipv6", &ipv6, N_("resolve IPv6 addresses only")),
> Technically OK to mention resolve, but does it give any information to the user ?
> s/resolve IPv4 addresses only/use IPv4 addresses only/

I suppose "use" is shorter and just as informational.
Will prepare that for v2.

> > @@ -970,6 +973,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
> >  	remote = remote_get(option_origin);
> >  	transport = transport_get(remote, remote->url[0]);
> >  	transport_set_verbosity(transport, option_verbosity, option_progress);
> > +	transport_set_family(transport, ipv4, ipv6);
> >  
> Does it make sense to name the variable into
> ipv4only (to make clear that it does not mean ipv4_allowed ?)
> (and similar in the rest of the code)

I actually had "only" in the variables originally, but didn't want to
line-wrap in builtin/push.c

Furthermore, the non-"only" name is used by the long switch (just like
in both curl(1) and rsync(1)), so I figured we should remain consistent
with what the user will see in documentation.

I think I will drop "ONLY" from the CONNECT_* macros instead...

Will await further comments and prepare v2 in a day or two.
Thanks for the comments.

  reply	other threads:[~2016-01-31  0:02 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-28 22:51 [PATCH] pass transport verbosity down to git_connect Eric Wong
2016-01-28 23:45 ` Junio C Hamano
2016-01-30  8:50   ` [PATCH v2] " Eric Wong
2016-01-30 13:13     ` [PATCH 2/1] support -4 and -6 switches for remote operations Eric Wong
2016-01-30 13:28       ` Eric Wong
2016-01-30 23:34       ` Torsten Bögershausen
2016-01-31  0:01         ` Eric Wong [this message]
2016-01-31  1:13           ` Jeff King
2016-02-03  4:09             ` [PATCH v2 " Eric Wong
2016-02-12 11:31               ` Eric Wong
2016-02-12 15:43                 ` Torsten Bögershausen
2016-01-31 16:03           ` [PATCH " Torsten Bögershausen
2016-01-28 23:53 ` [PATCH] pass transport verbosity down to git_connect Jeff King
2016-01-29  0:38   ` Eric Wong
2016-01-29  3:19     ` Junio C Hamano
2016-01-29  3:47       ` Jeff King
2016-01-29 17:34         ` Junio C Hamano
2016-01-29 17:41           ` Jeff King

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=20160131000144.GA10117@dcvr.yhbt.net \
    --to=normalperson@yhbt.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    --cc=tboegi@web.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.