> Quoting Alex Riesen <raa.lkml@xxxxxxxxx>: > Subject: Re: [PATCHv2] connect: display connection progress > > On 5/10/07, Michael S. Tsirkin <mst@xxxxxxxxxxxxxxxxxx> wrote: > >> >> What addresses were tried by connect? > >> > > >> >You are speaking about your patch reporting the IP on failure? > >> > >> Yes. Not on failure (not only). Every time an address is tried > >> to connect. > > > >Why not only on failure? IP addresses look ugly. > > So you can see DNS problems you wanted to uncover. I really just wanted git to tell me what it's doing, so that I know it's not actually blocked on network, not doing any work. > DNS is all about mapping names to that ugly IP. Yes, but so far git port does not seem to be commonly open on random IPs ;). > And DNS _problems_ often manifest themselves > by mapping the name to an unexpected IP. > Now that's really ugly So, let's print the IP if -v is set? Oh, look, now we'll have NET_QUIET NET_VERBOSE > >> >I think it makes sense, but it's a separate issue, isn't it? > >> > >> You are just about to make git_tcp_connect verbose, > >> are you not? > > > >Only if the flag is set. So git-fetch without -q qill be more verbose - > >but it already spits out a fair amount of data on screen. > > And so you added some more? Does not sound logical. > > How about cleaning up this (reduce the amount of date > on screen) Isn't this why we have -q? > and adding another verbosity level (with your > messages and IP) instead? What, yet another flag? Nooooooo -- MST - 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
