Jeff King <p...@peff.net> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to