Re: git clone silently aborts if stdout gets a broken pipe

[Jeff King <peff@peff.net>]

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