Jeff King <peff@xxxxxxxx> writes: > On Fri, Sep 21, 2012 at 09:49:40AM -0700, Junio C Hamano wrote: > >> > 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. -- 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