Jeff King <p...@peff.net> 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.
> 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.
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