From: Ryan Hendrickson <ryan.hendrickson@alum.mit.edu>
Date: Fri, 02 Aug 2024 22:14:13 GMT
Subject: Re: [PATCH v5] http: do not ignore proxy path
Message-ID: <7bb4bc3b-2280-3bda-c104-1dcb9e12db11@alum.mit.edu>
In-Reply-To: <xmqqikwia97c.fsf@gitster.g>

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

> Ryan Hendrickson <ryan.hendrickson@alum.mit.edu> writes:
>
>> 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.
>
> The easiest you can imagine is that it turns out the cut-off version
> of cURL for the feature turned out to be not 7.84, or versions of
> cURL shipped by some distros have backports of the feature to an
> older version that explicitly naming 7.84 causes more confusion than
> naming the exact feature we rely on, and we end up rephrasing the
> error message.  We have done such changes in the past, so it is not
> really speculating "hypothetical future errors", but applying common
> sense gained over years working on this project.

Okay, so is it a problem to also change the message in the test if that 
happens? My concern is that if I pick some fragment of the message to 
elide in the test, the message could still get reworded in a way that 
requires the test to be changed anyway. Even if not, the comment above it 
would likely need revision too; and if the test doesn't fail, whoever 
amends the message is unlikely to notice this.

The way the test is written in the current version of the patch, there is 
no ambiguity about what is being tested and what would need to change if 
the message changes. Future contributors can grep the code for references 
to that error message and find this test regardless of which part and how 
much of the message they choose to grep for. Shaving a dozen or so 
characters out of line is not more important than those considerations, is 
it?

R