git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Shawn O. Pearce" <spearce@spearce.org>
To: Jeff King <peff@peff.net>
Cc: Theodore Tso <tytso@mit.edu>, Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org
Subject: Re: [RFC/PATCH 2/2] make remote hangup warnings more friendly
Date: Wed, 4 Mar 2009 11:04:52 -0800	[thread overview]
Message-ID: <20090304190452.GJ14365@spearce.org> (raw)
In-Reply-To: <20090304084245.GB31798@coredump.intra.peff.net>

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

  reply	other threads:[~2009-03-04 19:06 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-01  0:03 [PATCH 1/4] Refactor list of environment variables to be sanitized Junio C Hamano
2009-03-01  0:03 ` [PATCH 2/4] git-init: inject some sanity to the option parser Junio C Hamano
2009-03-01  0:03   ` [PATCH 3/4] Add init-serve, the remote side of "git init --remote=host:path" Junio C Hamano
2009-03-01  0:03     ` [PATCH 4/4] " Junio C Hamano
2009-03-01  3:16     ` [PATCH 3/4] Add init-serve, the remote side of " Jeff King
2009-03-01  5:54       ` Junio C Hamano
2009-03-01 10:00         ` Jeff King
2009-03-01 17:04           ` Shawn O. Pearce
2009-03-03  6:50             ` Subject: [PATCH] Push to create Junio C Hamano
2009-03-03  7:09               ` Jay Soffian
2009-03-03  7:09               ` Jeff King
2009-03-03  7:37                 ` Jay Soffian
2009-03-03  7:39                   ` Jay Soffian
2009-03-03  7:56                   ` Junio C Hamano
2009-03-03  8:02                     ` Jay Soffian
2009-03-03  8:04                       ` Junio C Hamano
2009-03-03  8:04                       ` Junio C Hamano
2009-03-03  8:16                         ` Jay Soffian
2009-03-03  8:23                     ` Jeff King
2009-03-03 19:57                       ` Jay Soffian
2009-03-04  5:42                         ` Jeff King
2009-03-04  6:35                           ` Junio C Hamano
2009-03-04 13:06                           ` Jay Soffian
2009-03-03  7:55                 ` Junio C Hamano
2009-03-03  8:06                   ` Jeff King
2009-03-03  8:22                     ` Junio C Hamano
2009-03-03  8:27                       ` Jeff King
2009-03-03  8:30                         ` Junio C Hamano
2009-03-03  8:41                           ` Jay Soffian
2009-03-03  9:23                           ` Theodore Tso
2009-03-03 10:39                             ` Johannes Schindelin
2009-03-04 17:58                               ` Theodore Tso
2009-03-06  1:37                                 ` Miles Bader
2009-03-03 18:41                             ` Shawn O. Pearce
2009-03-04  8:32                               ` [RFC/PATCH 1/2] improve missing repository error message Jeff King
2009-03-04  9:19                                 ` Matthieu Moy
2009-03-04 10:35                                   ` Jeff King
2009-03-04 18:57                                 ` Shawn O. Pearce
2009-03-05 10:36                                   ` Jeff King
2009-03-04  8:42                               ` [RFC/PATCH 2/2] make remote hangup warnings more friendly Jeff King
2009-03-04 19:04                                 ` Shawn O. Pearce [this message]
2009-03-05 10:45                                   ` Jeff King
2009-03-03 21:08                   ` Subject: [PATCH] Push to create Daniel Barkalow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090304190452.GJ14365@spearce.org \
    --to=spearce@spearce.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).