"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

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

and it may or may not behave the same way as 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

Reply via email to