From: Junio C Hamano Date: Tue, 16 Apr 2013 19:02:00 GMT Subject: Re: [RFC/PATCH 0/2] Test the Git version string Message-ID: <7vip3ml2on.fsf@alter.siamese.dyndns.org> In-Reply-To: David Aguilar 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.