Jeff King <peff@xxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
