Peff, thanks for the feedback. as I mentioned in the cover letter for the reroll (which I am hoping you could Reviewed-by fully), I am including this extra patch on top that tries to clarify the format of the values, so that helper developers could adjust their implementations as needed. Carlo --- >8 --- Subject: [RFC PATCH 5/4] credential: document encoding assumptions for values Because of the similarity on the names of the keys with what is defined in RFC3986 is easy to assume the same rules would apply here. Make sure that the format and encoding is well defined to avoid helper developers assuming incorrectly. Signed-off-by: Carlo Marcelo Arenas Belón <carenas@xxxxxxxxx> --- Documentation/git-credential.txt | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/Documentation/git-credential.txt b/Documentation/git-credential.txt index 8d990e92fd..d72e85c874 100644 --- a/Documentation/git-credential.txt +++ b/Documentation/git-credential.txt @@ -113,9 +113,16 @@ separated by an `=` (equals) sign, followed by a newline. The key may contain any bytes except `=`, newline, or NUL. The value may contain any bytes except newline or NUL. -In both cases, all bytes are treated as-is (i.e., there is no quoting, -and one cannot transmit a value with newline or NUL in it). The list of -attributes is terminated by a blank line or end-of-file. +In both cases, all bytes are treated AS-IS (i.e., there is no quoting, +and one cannot transmit a value with newline or NUL in it). + +Values start inmediately after the '=' separator and could consist of 0 +or more bytes until the required newline delimiter. No assumptions of case +insensitivity can be made on their contents and if a specific encoding is +required (e.g. "UTF-8") then the byte contents should be re-encoded before +use. + +The list of attributes is terminated by a blank line or end-of-file. Git understands the following attributes: -- 2.26.2.686.gfaf46a9ccd
