David Aguilar <davvid@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html