"Philip Oakley" <philipoak...@iee.org> writes:

> How about
>    * E.g. git gui uses the extended regular expression "^git version
> [1-9]+(\.[0-9]+)+.*"
>    * to check for an acceptable version string.
>
> The ERE is from git-gui.sh:L958.

That is exactly the kind of guarantee we do _not_ want to give.

> ... Hence my suggestion of the basic test that a "passing" git
> would produce a consistent version string.

I have been assuming that you are trying to avoid an exchange like
this one we had in the past:

  http://thread.gmane.org/gmane.comp.version-control.git/216923/focus=217007

I also have been assuming that you are pushing to limit the possible
versioning scheme, but I do not know what that extra limitation
would achieve in the real world.

By sticking to the pattern "git gui" happens to use, "git gui" may
be able to guess that the next version of Git says it is verison
"1.8.3".  That is the _only_ thing your "test" buys.

But having parsed the "1.8.3" substring out of it, "git gui" does
not know anything about what 1.8.3 gives it.  As far as it is
concerned, it is a version whose "git version" output it has never
seen (unless it has been kept up to date with the development of
Git).

By matching against "git version [1-9]+(\.[0-9]+)+", it is accepting
that future versions may break assumptions it makes for some known
versions (which is warranted) and all future versions (which is
unwarranted) of Git.  Maybe the version 2.0 of Git adds all changes
in the directory "d", including removals, when you say "git add d",
but it may have assumed that with Git version 1.5.0 or newer, saying
"git add d" would result in added and modified inside that directory
getting updated in the index, but paths removed from the working
tree will stay in the index.

The only thing the scripts that read from the output of "git
version" can reliably tell is if it is interacting with a version of
Git it knows about.  If it made any unwarranted assumption on the
versions it hasn't seen, it has to be fixed in "git gui" _anyway_.

Of course, we would not change the output of "git version"
willy-nilly without good reason, but that is a different topic.

So I do not know what you want to achieve in the real world with 
that extra limitation on the "git version" output format.

Maybe you are proposing something else.  I dunno.
--
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