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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 16, 2013, 19:02 UTC
Message-ID: <7vip3ml2on.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CAJDDKr7WKwt10sCRTbm8gdhwEUKSYuQxtPDVm7usTm2ZHryk9g@mail.gmail.com>

David Aguilar <davvid@gmail.com> writes:

Show 11 quoted lines

> 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.