From: "Junio C Hamano" <>
Sent: Monday, April 15, 2013 2:39 AM
"Philip Oakley" <> 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
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 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

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

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


To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to