Re: [PATCH 2/3] receive-pack: send pack-processing stderr over sideband

Jeff King [off-list ref] writes:

On Fri, Sep 21, 2012 at 09:49:40AM -0700, Junio C Hamano wrote:

quoted

quoted

  2. No matter what the cause, we are probably better off
     showing the errors to the client. If the client and the
     server admin are not the same entity, it is probably
     much easier for the client to cut-and-paste the errors
     they see than for the admin to try to dig them out of a
     log and correlate them with a particular session.

I agree with the "probably" above (and also with points 1 and 3),
but it at the same time feel a bit iffy.  The server side would lose
log entries to check when the operator observes higher error rate
and starts suspecting something recently broke, and the lost clue
cannot be recovered without contacting the pushers, no?

Yeah, that is true, although that is already the case with ssh pushes.
Conversely, it also means that servers using the ssh transport have lost
the option of redirecting the server-side stderr (e.g., with a wrapper
around git-receive-pack) to a log if they were already doing so.

Yes.

However, this does make things more consistent with upload-pack, which
connects the stderr of pack-objects to sideband (which it must to handle
progress). Furthermore, many of the messages from receive-pack are
handled by rp_error, which sends to the sideband. So if you were
monitoring your git purely by trying to capture stderr, you were already
only getting a fraction of the real data.

The comments were not meant as a rejection notice ;-) Just to see if
some server operators have input on the matter.

I personally do not think tee-ing the error output is worth it; it
would be reasonably simple to arrange, and the server operators who
want it can ask later if that is need.

Thanks.