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.

On Fri, Sep 21, 2012 at 10:25:24AM -0700, Junio C Hamano wrote:

quoted

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 know.  But your comment made me second-guess a little whether
anybody would be inadvertently hurt, but thinking it through and writing
it out helped convince myself that it's the right thing to do.

One of the hardest parts of working on a mature software project is not
just thinking about what you want to do, but thinking about what
everyone else wants to do (or is doing). So it never hurts to
double-check your assumptions in such a case, and I don't mind working
through these "what ifs" even if they end in us doing the original
thing. I hope you do not mind reading them too much. :)

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.

Agreed.

-Peff