David Aguilar <dav...@gmail.com> 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html