Re: [RFC/PATCH 0/2] Test the Git version string

David Aguilar [off-list ref] writes:

The "regression" is that there are scripts and tools in the wild that
need to know the git version when deciding whether or not to use some
new feature.

e.g. "git status --ignore-submodules=dirty" did not appear until git 1.7.2.
A script may want to use this flag, but it will only want to use it
when available.

If this string started saying "The Git Version Control System v2.0" then these
scripts would be "broken" since they would no longer recognize this as a
"post-1.7.2 Git".

Blacklisting known-bad version and hoping all other versions
including the ones you have never seen to behave in the way you
expect usually works but there is a limit.

A change to say "The Git Version Control System %s" will not happen
willy-nilly, but when there is a good reason to do so, we would.

I do not think a test that hardcodes the output is a good way to
make sure a change is being done with a good reason.  After all, a
patch that updates the "git version %s" string can just update the
expected output in the same patch.  The only reason such a change
will be caught is because during the review, somebody notices that
the change touches the expected output of a test; for that to
reliably protect the output, the test *has* to be commented to say
that this expected output should be changed very carefully.

A much better solution would be to leave that "very carefully"
comment next to the in-code string to warn people about ramifiations
of changing it.