Re: [PATCH] protocol upload-pack-v2

From: Kyle J. McKay <mackyle@gmail.com>
Date: Mar 10, 2015, 19:36 UTC
Message-ID: <96E9559D-9B15-464D-AC9E-8C17229A0A78@gmail.com>
In-Reply-To: <CACsJy8AuCAfHMbnV3N4ZyZCCqF6WAs_k2dS_Y1ZccWAzWm0yVA@mail.gmail.com>

On Mar 9, 2015, at 18:38, Duy Nguyen wrote:

Show 13 quoted lines

> A minor point on capability negotiation. I remember why I passed
> capabilities via command line instead of this proposal. With this
> proposal, daemon.c does not recognize "i18n" capability and cannot
> switch to the correct language before it reports an error.
>
> But perhaps I approached it the wrong way. Instead of letting the
> daemon produce non-English language directly, if could sort of
> standardize the messages and send an error code back in "ERR" line,
> together with an English message (current pack-protocol.txt says "ERR"
> followed by explanation-text). The client can use this error code to
> print non-English messages if it wants to. Perhaps we can reuse http
> (or ftp) return codes or some other protocol then customize to fit
> Git's needs.

May I suggest that you take a look at RFC 2034 [1]. It describes almost exactly this same situation and how SMTP was enhanced to support error code numbers that could then be translated.

No reason this enhancement needs to be restricted to protocol v2 if it's just an "enhancedstatuscodes" capability the server sends back to indicate that its ERR text is in that format.

-Kyle

[1] http://tools.ietf.org/html/rfc2034