On Wed, Sep 18, 2013 at 12:31:23PM -0700, Junio C Hamano wrote: > > Hrm, this actually breaks t5701, which expects "clone 2>err" to print > > nothing to stderr. > > Hmm, where in t5701? Ah, you meant t5702 and possibly t5601. Yes, sorry, I meant t5702. > I actually think "it is long and not meant to be seen sequentially" > is a bad classifier; these new messages are also progress report in > that it reports "we are now in this phase". So if I were to vote, I > would say we should apply the same progress-silencing criteria, > preferrably by not checking isatty() again, but by recording the > decision we have already made when squelching the progress during > the transfer in order to make sure they stay consistent. Unfortunately that decision is made in the transport code, not by clone itself. We can cheat and peek at "transport->progress" after initializing the transport. That would require some refactoring, though; we print "Cloning into" before setting up the transport. And we do not even tell the transport about our progress options if we are doing a local clone. If we wanted to _just_ suppress "Checking connectivity" (and not "Cloning into..."), that's a bit easier. And I could see an argument that the former is the only one that falls into the "progress report" category. > > Also, we should arguably give the "Cloning into..." message the same > > treatment. We have printed that to stdout for a very long time, so there > > is a slim chance that somebody actually tries to parse it. But I think > > they are wrong to do so; we already changed it once (in 28ba96a), and > > these days it is internationalized, anyway. > > Good thinking. Please make it so ;-) OK. I've squashed the "use stderr" patches into one, and added a patch on top to correctly check the progress flag. [1/2]: clone: send diagnostic messages to stderr [2/2]: clone: treat "checking connectivity" like other progress -Peff -- 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