On 2016-01-29 04.04, Junio C Hamano wrote: > Eric Wong <normalperson@xxxxxxxx> writes: > >> getaddrinfo() may return multiple addresses, not all of which >> are equally performant. In some cases, a user behind a non-IPv6 >> capable network may get an IPv6 address which stalls connect(). > > I'd assume that you are not solving a hypothetical problem, but you > may (at least sometimes) have to reach outside world from such a > network environment. I further assume that git_tcp_connect() is not > the only activity you do from such a network, and other network > activities are similarly affected. > > How do you work around the same issue for connections that do not go > through git_tcp_connect()? The same issue would affect Git traffic > going over git-remote-curl, and also your usual Web browser traffic, > no? > > What I am getting at is if it is saner to solve the issue like how > curl(1) solves it with its -4/-6 command line options, e.g. by > adding a pair of configuration variables "net.ipv[46] = true/false". (Please don't do parallel connects as a default) I like the -4 / -6 Out of my head these kind of setups are not desired. (getaddrinfo returns an address and the the following connect fails) But it may be hard to fully avoid them in practice, and some RFC have been written, this may be a starting point: https://www.rfc-editor.org/rfc/rfc5014.txt -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html