"Philip Oakley" <philipoak...@iee.org> 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? 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
and it may or may not behave the same way as 1.8.2.1 depending on
what trait you are interested in.
--
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
