From: "Junio C Hamano" <gitster@xxxxxxxxx>
Sent: Tuesday, April 16, 2013 11:35 PM
"Philip Oakley" <philipoakley@xxxxxxx> writes:
int cmd_version(int argc, const char **argv, const char *prefix)
{
+ /*
+ * The format of this string should be kept stable for
compatibility
+ * with external projects that rely on the output of "git version".
This 'tantalizes without telling', the same complaint that is given
often for over-succinct commit messages.
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.
Shouldn't the expected format of our known external project also be
indicated?
...
printf("git version %s\n", git_version_string);
It is fairly clear from the commented code that the only guarantee
they will be getting is that it begins with a string "git version ".
I read the code the opposite way. It says "This is the code to be
changed" if you (anyone doing tweaks) want a special version string.
git_version_string[] has anything of the builder's choice. I am not
sure if there anything more to "indicate".
Really, if you run
$ git version
and you get "Git Source Code Management Version 3.56" from its
output, it is likely that the version is very different from what
you know, and you should not assume any your assumption would hold.
Again I am reading this from the opposite side. There would be no
assumption of difference if it _passed_ the test scripts. Unfortunately
it wouldn't be friendly to other tools (like git gui). Hence my
suggestion of the basic test that a "passing" git would produce a
consistent version string. It still allows the supplier's suffixes to be
added, but not the prefixes. The test suite tests that git is 'good
enough for most usages and picks up regressions. No?
Obvious inconsistent special versions would fail in many other places.
Or mention "such as git gui"?
I do not see what it would buy us. It is not like it is OK as long
as we upadte Git gui at the same time.
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