From: Junio C Hamano Date: Tue, 04 Nov 2025 18:40:31 GMT Subject: Re: [PATCH v3] doc: clarify server behavior for invalid 'want' lines in HTTP protocol Message-ID: In-Reply-To: <20251104155127.1079-1-qjessa662@gmail.com> Queen Ediri Jessa writes: > Update the documentation to clearly describe how the server responds when a > client sends an invalid or malformed `want` line during the HTTP protocol > exchange. This improves understanding of Git’s behavior when handling > incorrect object requests and helps developers detect and handle such > protocol issues accurately. > > Signed-off-by: Queen Ediri Jessa > > --- > > Changes since v1: > - Rephrased the explanation to be more concise and aligned with reviewer > feedback. > - Clarified that the server includes the offending object name in its error > message. > - Adjusted tone to describe the expected behavior rather than prescribing > implementation-specific messages. > - Improved readability and technical consistency of the section. > > Documentation/gitprotocol-http.adoc | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) Perfect. Hopefully your future contributions we won't have to worry about these procedural issues. > diff --git a/Documentation/gitprotocol-http.adoc b/Documentation/gitprotocol-http.adoc > index d024010414..f3f48d3f35 100644 > --- a/Documentation/gitprotocol-http.adoc > +++ b/Documentation/gitprotocol-http.adoc > @@ -443,7 +443,10 @@ If no "want" objects are received, send an error: > TODO: Define error if no "want" lines are requested. > > If any "want" object is not reachable, send an error: > -TODO: Define error if an invalid "want" is requested. > +When a Git server receives an invalid or malformed `want` line, it > +responds with an error message that includes the offending object name. > +This clarifies the expected behavior for Git implementations and helps > +clients detect protocol issues accurately during fetch operations. > > Create an empty list, `s_common`. I am not sure what "This clarifies the expected behavior of Git implementations" here, though. Who exactly are "implementations" that the clarification is given, and what are they expected to do in response? What does it really mean to detect "accurately" in this case? For a client that received this error, they know what they sent as "want", and they are told that the other side does not like that object name, but then what would they do after that? The last two lines invite more questions than it answers. Perhaps we are better off without them? I dunno. Thanks.