On Thu, Aug 04, 2016 at 01:45:11PM -0700, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > If we get a write error writing to a trace descriptor, the > > error isn't likely to go away if we keep writing. Instead, > > you'll just get the same error over and over. E.g., try: > > > > GIT_TRACE_PACKET=42 git ls-remote >/dev/null > > > > You don't really need to see: > > > > warning: unable to write trace for GIT_TRACE_PACKET: Bad file descriptor > > > > hundreds of times. We could fallback to tracing to stderr, > > as we do in the error code-path for open(), but there's not > > much point. If the user fed us a bogus descriptor, they're > > probably better off fixing their invocation. And if they > > didn't, and we saw a transient error (e.g., ENOSPC writing > > to a file), it probably doesn't help anybody to have half of > > the trace in a file, and half on stderr. > > Yes, I think I like this better than "we cannot open the named file, > so let's trace into standard error stream" that is done in the code > in the context of [3/7]. We should do the same over there. Yeah, I was tempted to strip that out, too. I'll look into preparing a patch on top. -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