Jeff King <peff@xxxxxxxx> writes: > On Thu, Jan 28, 2016 at 07:19:30PM -0800, Junio C Hamano wrote: > >> I just reviewed the output that are protected by CONNECT_VERBOSE; >> they look somewhere between pure debugging aid (like the protocol >> dump that are shown by "fetch -vv") and progress display, and at >> least to me they are much closer to the latter than the former, in >> the sense that they are not _so_ annoying as the protocol dump that >> are clearly not meant for the end users, and that they say "I am >> looking up this host's address", "Now connecting to this host:port", >> etc. >> >> So, I personally find this addtional output not _too_ bad if we give >> it with "fetch -v" (not limiting to "fetch -vv"). > > Yeah, I do not feel that strongly, and am OK if it is attached to a > single "-v". I don't think we make any promises about scraping stderr, > so it is really just about end-user experience. It is mostly just my > gut feeling on what I'd expect based on other parts of git (especially > "fetch -vv" in other circumstances). Yeah, after re-reading the messages in this thread, I realize that I missed the fact that you do consider these CONNECT_VERBOSE messages as debugging aid and from that point of view "fetch -v" that shows these messagse in addition to what you get from "fetch" may be a bad idea. But after inspecting what CONNECT_VERBOSE would add to the output, I am inclined to say that, especially if some of these steps can exhibit multi-second stalls, they fall more into the "progress indicator" (aka "do not worry, we are not stuck, be patient") category than "debugging aid" category. The former includes "remote: Counting objects..." that is shown by default (you need to give --quiet to squelch). So I think it is OK to show the CONNECT_VERBOSE messages with "fetch -v"; if somebody feels strongly that these messages should be shown unless --quiet is given, I might even be persuaded to agree, but I am not that somebody, so... -- 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