At 2024-08-02 14:47-0700, Junio C Hamano <gitster@xxxxxxxxx> sent:
Ryan Hendrickson <ryan.hendrickson@xxxxxxxxxxxx> 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
