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

Reply via email to