Re: [PATCH 4/6] send-pack: improve unpack-status error messages

2 messages, 2 authors, 2017-03-08 · open the first message on its own page

Re: [PATCH 4/6] send-pack: improve unpack-status error messages

From: Junio C Hamano <hidden>
Date: 2017-03-07 23:03:38

Jeff King [off-list ref] writes:
When the remote tells us that the "unpack" step failed, we
show an error message. However, unless you are familiar with
the internals of send-pack and receive-pack, it was not
clear that this represented an error on the remote side.
Let's re-word to make that more obvious.

Likewise, when we got an unexpected packet from the other
end, we complained with a vague message but did not actually
show the packet.  Let's fix that.
Both make sense.
And finally, neither message was marked for translation. The
message from the remote probably won't be translated, but
there's no reason we can't do better for the local half.
Hmm, OK.
quoted hunk
Signed-off-by: Jeff King <redacted>
---
 send-pack.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/send-pack.c b/send-pack.c
index 243633da1..83c23aef6 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -134,9 +134,9 @@ static int receive_unpack_status(int in)
 {
 	const char *line = packet_read_line(in, NULL);
 	if (!skip_prefix(line, "unpack ", &line))
-		return error("did not receive remote status");
+		return error(_("unable to parse remote unpack status: %s"), line);
 	if (strcmp(line, "ok"))
-		return error("unpack failed: %s", line);
+		return error(_("remote unpack failed: %s"), line);
 	return 0;
 }

Re: [PATCH 4/6] send-pack: improve unpack-status error messages

From: Jeff King <hidden>
Date: 2017-03-08 12:52:24

On Tue, Mar 07, 2017 at 02:56:27PM -0800, Junio C Hamano wrote:
Jeff King [off-list ref] writes:
quoted
When the remote tells us that the "unpack" step failed, we
show an error message. However, unless you are familiar with
the internals of send-pack and receive-pack, it was not
clear that this represented an error on the remote side.
Let's re-word to make that more obvious.

Likewise, when we got an unexpected packet from the other
end, we complained with a vague message but did not actually
show the packet.  Let's fix that.
Both make sense.
quoted
And finally, neither message was marked for translation. The
message from the remote probably won't be translated, but
there's no reason we can't do better for the local half.
Hmm, OK.
I'll admit that I don't actually use the translations myself, being a
native English speaker.  So I am just guessing that somebody for whom
English is a second language would rather see the first half in a more
intelligible format. That at least tells them what the second half _is_,
so they might be able to search for the error with more context.

If my guess is wrong, though, I'm happy to retract that part or bump it
out to a separate patch.

-Peff
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help