Re: [PATCH v5] http: do not ignore proxy path

[Ryan Hendrickson <ryan.hendrickson@alum.mit.edu>]

[-- Attachment #1: Type: text/plain, Size: 2408 bytes --]

At 2024-08-02 14:13-0700, Junio C Hamano <gitster@pobox.com> sent:

>>>>>> Is this blocking feedback? This strikes me as speculative
>>>>>> over-engineering
>>>>>
>>>>> No, it is loosening a pattern that is overly tight and as a side
>>>>> effect shortening the line to more readable length ;-).
>>>>
>>>> Blocking or not?
>>>
>>> If we are updating anyway, that question is irrelevant, no?  This
>>> version may hit 'seen' but until the next version comes it will not
>>> advance to 'next'.
>>
>> I can't figure out what you mean by this so I am going to proceed as
>> if you had simply said ‘non-blocking’.
>
> It does not make much sense to ask if a suggestion is "blocking" or
> "non-blocking".  If you respond with a reasonable explanation why
> you do not want to take a suggestion, I may (or may not) say that
> your reasoning makes sense.  IOW, making me say "it is blocking"
> means you want to me to say that I won't listen to you no matter
> what you say.  That is rarely be the case.

I want you to do what Documentation/ReviewingGuidelines.txt says reviewers 
should do:

- When providing a recommendation, be as clear as possible about whether you
   consider it "blocking" (the code would be broken or otherwise made worse if an
   issue isn't fixed) or "non-blocking" (the patch could be made better by taking
   the recommendation, but acceptance of the series does not require it).
   Non-blocking recommendations can be particularly ambiguous when they are
   related to - but outside the scope of - a series ("nice-to-have"s), or when
   they represent only stylistic differences between the author and reviewer.

Because I would rather not have what is likely to be a highly subjective 
argument about this particular choice in a test script if we don't have 
to have one.

I would also rather not put time into figuring out how best to rename the 
function "old_curl_version" if it no longer checks for the particular 
error produced when the curl version is too old, nor would I want to think 
ahead about whether it is correct for these tests that use this function 
to continue to pass if different variations on this error are raised. 
There is one qualifying error currently, and that's what the test matches 
against. Matching against hypothetical future errors is speculative 
overengineering if it is not obvious how the errors will vary and what it 
may mean if they do.

R