From: "Junio C Hamano" <gitster@xxxxxxxxx>
Sent: Monday, April 15, 2013 2:39 AM
"Philip Oakley" <philipoakley@xxxxxxx> writes:
If the "parsing" is done for white/blacklist purposes, is there a
need to straight-jacket the verison string format like this series?
The purpose is to document what we felt we could guarantee, and that
which was open to variation, so that those, like the Git-Gui, can
code
in a sensible check for the version. Two digits (X.Y) should pass the
existing Git Gui check.
I'll drop the length limit, and keep to an X.Y check
Is the end of t0000-basic.sh a sensible place for the check?
Sorry, but I still do not understand what you are trying to achieve.
What kind of benefit are you envisioning out of this?
The purpose of tests is to detect mistakes and spot regressions.
A change to the 'git version X.Y.z' string would be a regression, as I
spotted earlier, as it conflicts with expectations of standard
programmes such as git-gui.
For a future
version, people would not know what incompatibilities it would
introduce, so
case "$(git version)" in
"git verison"[2-9].*)
echo unsupported version
exit 1
;;
esac
is a nonsense check.
For all released versions, people know how they looked like
and we
do not have anything further to specify. Git 1.5.0 will forever
identify itself as:
$ git version
git version 1.5.0
Worse yet, for an untagged version, you may get something like
git version 1.8.2.1-515-g78d2372
However, if it passes the test [all the tests], one expects it will be
reasonably (almost completely) compatibility with external expectations,
such as those of git gui.
The questions I'm posing is from the other direction - use of tests for
quality control.
and it may or may not behave the same way as 1.8.2.1 depending on
what trait you are interested in.
That will depend on the tests if [deliberately?] failed.
I'll tidy up the patches and commit meesage and see how it looks then.
Philip
--
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