Re: [RFC/PATCH 2/2] make remote hangup warnings more friendly

From: Shawn O. Pearce <spearce@spearce.org>
Date: Mar 4, 2009, 19:04 UTC
Message-ID: <20090304190452.GJ14365@spearce.org>
In-Reply-To: <20090304084245.GB31798@coredump.intra.peff.net>

Jeff King <peff@peff.net> wrote:

Show 12 quoted lines

> When a user asks to do a remote operation but the remote
> side thinks the operation is invalid (e.g., because the user
> pointed to a directory which is not actually a repository),
> then we generally end up showing the user two fatal
> messages: one from the remote explaining what went wrong, and
> one from the local side complaining of an unexpected hangup.
> 
> For example:
> 
>   $ git push /nonexistent master
>   fatal: '/nonexistent' does not appear to be a git repository
>   fatal: The remote end hung up unexpectedly

Show 6 quoted lines

> In this case, the second message is useless noise, and the
> user is better off seeing just the first.
> 
> This patch tries to suppress the "hung up" message when it
> is redundant (but still exits with an error code, of
> course).

Hmm.  It would be nice to clean up these messages, but I
think the better way to do it is...

>      I think this would be improved somewhat with stderr processing to:
> 
>        remote: sh: bogus: command not found

... because then we can have positive proof that the remote said something to the user, and we tagged it as being from the remote side, just like we do with progress data in sideband, and then the user can work from that information. Any local side errors are very likely caused by the remote errors, so we shouldn't bother displaying them.

But its a lot more invasive of a patch to setup stderr processing for pipe/SSH.

Actually, the remote stderr processing is desired for more than
just the bad path case.  Its good for when the remote aborts with
a write error from a write_or_die(), at least we know it was on
the remote side and not the local.  Its good for when the remote
shell says a "git-upload-pack: command not found".  Its good for
when the remote hook prints output, the client knows it came from
the remote side and not something local, so its messages should be
read in the context of the remote side.  Etc.

-- 
Shawn.