When we encounter an error in remote-curl, we generally just
report it to stderr. There is no need for the user to care
that the "could not connect to server" error was generated
by git-remote-https rather than a function in the parent
git-fetch process.

However, when the error is in the protocol between git and
the helper, it makes sense to clearly identify which side is
complaining. These cases shouldn't ever happen, but when
they do, we can make them less confusing by being more

Signed-off-by: Jeff King <p...@peff.net>
 remote-curl.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/remote-curl.c b/remote-curl.c
index a619b64..1f6905d 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -949,7 +949,7 @@ int main(int argc, const char **argv)
        if (argc < 2) {
-               error("remote needed");
+               error("remote-curl: usage: git remote-curl <remote> [<url>]");
                return 1;
@@ -970,14 +970,14 @@ int main(int argc, const char **argv)
        do {
                if (strbuf_getline(&buf, stdin, '\n') == EOF) {
                        if (ferror(stdin))
-                               error("error reading command stream");
+                               error("remote-curl: error reading command 
stream from git");
                        return 1;
                if (buf.len == 0)
                if (starts_with(buf.buf, "fetch ")) {
                        if (nongit)
-                               die("Fetch attempted without a local repo");
+                               die("remote-curl: fetch attempted without a 
local repo");
                } else if (!strcmp(buf.buf, "list") || starts_with(buf.buf, 
"list ")) {
@@ -1014,7 +1014,7 @@ int main(int argc, const char **argv)
                } else {
-                       error("unknown command '%s'", buf.buf);
+                       error("remote-curl: unknown command '%s' from git", 
                        return 1;
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to