should pushbuffer capture server messages?

[Danek Duvall]

Matt Mackall wrote:

> > Everything functions just fine, but I believe that the push/popbuffer calls
> > were there to sop up that extraneous output, and that's no longer happening
> > as of changeset 5884812686f7.  (Yes, we're pretty far behind :( )  It
> > appears that we used to have a consistent ui object throughout, but with
> > the introduction of peers, that changes around, and the new ui objects
> > don't copy the buffer or buffering status.
> 
> It's actually not peers that's the issue, it's us removing some bugs in
> the handling of ui objects. Before they were leaking local settings to
> secondary repos, now they're cleanly separated.

Okay; I wasn't sure if the remoteui() call wasn't copying enough
information ...

> > I notice that "hg sum --remote" shows the same garbage, so I'm not sure
> > whether my expectations are off and the ssh server is being stupid and
> > needs to be fixed, whether there's a bug in hg (in hg.remoteui()?) or
> > whether my code is just not doing the right thing here.
> 
> Definitely sounds like the ssh server being stupid to me. Mercurial's ssh
> sessions are pty-less, remote servers should create non-interactive
> shells with zero spew. Test with 'ssh host date', if you get spew other
> than the date, it's borked. Bonus negative points for it being on stdout.

It's not quite that bad -- the messages are being sent to stderr.  But the
server shunts connections off via ForceCommand to a script that detects "hg
serve" commands, and runs those as a special user, regardless of who's
connecting.  For some reason, that script has some ... verbose output when
running "hg serve" but not anything else; I've no idea why.  I'm sure I can
get that changed, particularly if there's no longer a way to work around it
from cadmium.  I just wanted to make sure that's what my option was.

Thanks,
Danek