Jeff King <> 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
More majordomo info at

Reply via email to