{"thread":{"id":"33508","subject":"[RFC/PATCH 0/2] Test the Git version string","startedAt":"2013-04-14T14:27:24Z","lastAt":"2013-04-16T21:22:57Z","messageCount":11,"participants":["Philip Oakley","Junio C Hamano","David Aguilar"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"214209","messageId":"1365949646-1988-1-git-send-email-philipoakley@iee.org","threadId":"33508","inReplyTo":null,"subject":"[RFC/PATCH 0/2] Test the Git version string","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-04-14T14:27:24Z","receivedAt":"2013-04-14T14:27:24Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"In $gmane/217004 I was noted that the git version string is used\nin the wild for confirming which git version is in use.\n\nThis patch series seeks to add tests for the version string format\nand document it.\n\nThe key questions to be answered are:\n* should the test be inside t0000, or somewhere else?\n* should the version string be limited to one line, <80 characters?\n* how to format the asciidoc of the ERE.\n\nPhilip Oakley (2):\n test git version string\n Doc: State the exact git version string\n\n Documentation/git.txt | 4 ++++\n t/t0000-basic.sh | 8 ++++++++\n 2 files changed, 12 insertions(+)\n\n-- \n1.8.1.msysgit.1\n"},{"id":"214210","messageId":"1365949646-1988-2-git-send-email-philipoakley@iee.org","threadId":"33508","inReplyTo":"1365949646-1988-1-git-send-email-philipoakley@iee.org","subject":"[RFC/PATCH 1/2] test git version string","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-04-14T14:27:25Z","receivedAt":"2013-04-14T14:27:25Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"The git version string is used in the wild, and in git gui,\nfor capability checking purposes. Test the string format\nand version X.Y.Z number.\n\nThe version string shall be:\n* a single line\n* less that 80 characters\n* start with `git version `\n* with a following numeric X.Y.Z version.\n\nThe remaining characters are undefined.\n\nSigned-off-by: Philip Oakley \n---\n\nShould this be applied to t0000, or another test file?\nShould the version string be always limited to one line?\nShould the maximum string length be <80 characters?\nIs egrep OK, or should I use grep with a longer BRE?\n\n t/t0000-basic.sh | 8 ++++++++\n 1 file changed, 8 insertions(+)\n\ndiff --git a/t/t0000-basic.sh b/t/t0000-basic.sh\nindex cefe33d..052afca 100755\n--- a/t/t0000-basic.sh\n+++ b/t/t0000-basic.sh\n@@ -610,4 +610,12 @@ test_expect_success 'very long name in the index handled sanely' '\n \ttest $len = 4098\n '\n \n+test_expect_success 'git version string X.Y.Z' '\n+\tgit --version >verstring &&\n+\ttest_line_count = 1 verstring &&\n+\tlen=$(wc -c verstring | sed \"s/[^0-9]//g\") &&\n+\ttest $len -lt 80 &&\n+\tegrep -q \"^git version [0-9]+\\.[0-9]+\\.[0-9]+.*\" verstring\n+'\n+\n test_done\n-- \n1.8.1.msysgit.1\n"},{"id":"214211","messageId":"1365949646-1988-3-git-send-email-philipoakley@iee.org","threadId":"33508","inReplyTo":"1365949646-1988-1-git-send-email-philipoakley@iee.org","subject":"[RFC/PATCH 2/2] Doc: State the exact git version string","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-04-14T14:27:26Z","receivedAt":"2013-04-14T14:27:26Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Provide the regular expression that matches the\n'git --version' strings.\n\nScripts in the wild, including 'git gui', check the git version.\n\nSigned-off-by: Philip Oakley \n---\n\nShould the string be described by a regular expression?\n\nHow to format the regular expression for asciidocs - it doesn't\nget made correctly - I'm not sure what special magic incantation\nis needed here.\n\n Documentation/git.txt | 4 ++++\n 1 file changed, 4 insertions(+)\n\ndiff --git a/Documentation/git.txt b/Documentation/git.txt\nindex 7efaa59..627e462 100644\n--- a/Documentation/git.txt\n+++ b/Documentation/git.txt\n@@ -365,6 +365,10 @@ OPTIONS\n -------\n --version::\n \tPrints the Git suite version that the 'git' program came from.\n+\tThe version string is a single line that matches the extended\n+\tregular expression\n+\t'^git version [0-9]+\\.[0-9]+\\.[0-9]+.*'\n+\tand is less than 80 characters.\n \n --help::\n \tPrints the synopsis and a list of the most commonly used\n-- \n1.8.1.msysgit.1\n"},{"id":"214228","messageId":"7v8v4k6hp2.fsf@alter.siamese.dyndns.org","threadId":"33508","inReplyTo":"1365949646-1988-1-git-send-email-philipoakley@iee.org","subject":"Re: [RFC/PATCH 0/2] Test the Git version string","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-14T19:22:17Z","receivedAt":"2013-04-14T19:22:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Philip Oakley writes:\n\n> This patch series seeks to add tests for the version string format\n> and document it.\n>\n> The key questions to be answered are:\n> * should the test be inside t0000, or somewhere else?\n> * should the version string be limited to one line, <80 characters?\n\nOne line, perhaps, but I do not think any byte-limit is reasonable.\n\nIt is unreasonable to limit the form to X.Y.Z; after we hit Git 2.0,\nit is likely that we would go to two-decimals.\n\nIf the \"parsing\" is done for white/blacklist purposes, is there a\nneed to straight-jacket the verison string format like this series?\n"},{"id":"214233","messageId":"79879228B71A45A48A961F5B1880B61F@PhilipOakley","threadId":"33508","inReplyTo":"7v8v4k6hp2.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH 0/2] Test the Git version string","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-04-14T21:26:30Z","receivedAt":"2013-04-14T21:26:30Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Junio C Hamano\" \nSent: Sunday, April 14, 2013 8:22 PM\n> Philip Oakley writes:\n>\n>> This patch series seeks to add tests for the version string format\n>> and document it.\n>>\n>> The key questions to be answered are:\n>> * should the test be inside t0000, or somewhere else?\n>> * should the version string be limited to one line, <80 characters?\n>\n> One line, perhaps, but I do not think any byte-limit is reasonable.\n\nOK\n\n>\n> It is unreasonable to limit the form to X.Y.Z; after we hit Git 2.0,\n> it is likely that we would go to two-decimals.\n\nAh. And then maintenance releases could be the .Z maybe. I suppose it \nwill depend on circumstances.\n\n>\n> If the \"parsing\" is done for white/blacklist purposes, is there a\n> need to straight-jacket the verison string format like this series?\n\nThe purpose is to document what we felt we could guarantee, and that \nwhich was open to variation, so that those, like the Git-Gui, can code \nin a sensible check for the version. Two digits (X.Y) should pass the \nexisting Git Gui check.\n\nI'll drop the length limit, and keep to an X.Y check\n\nIs the end of t0000-basic.sh a sensible place for the check?\n\n> --\nPhilip \n"},{"id":"214251","messageId":"7vli8k4lnj.fsf@alter.siamese.dyndns.org","threadId":"33508","inReplyTo":"79879228B71A45A48A961F5B1880B61F@PhilipOakley","subject":"Re: [RFC/PATCH 0/2] Test the Git version string","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-15T01:39:44Z","receivedAt":"2013-04-15T01:39:44Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Philip Oakley\" writes:\n\n>> If the \"parsing\" is done for white/blacklist purposes, is there a\n>> need to straight-jacket the verison string format like this series?\n>\n> The purpose is to document what we felt we could guarantee, and that\n> which was open to variation, so that those, like the Git-Gui, can code\n> in a sensible check for the version. Two digits (X.Y) should pass the\n> existing Git Gui check.\n>\n> I'll drop the length limit, and keep to an X.Y check\n>\n> Is the end of t0000-basic.sh a sensible place for the check?\n\nSorry, but I still do not understand what you are trying to achieve.\n\nWhat kind of benefit are you envisioning out of this? For a future\nversion, people would not know what incompatibilities it would\nintroduce, so\n\n\tcase \"$(git version)\" in\n\t\"git verison\"[2-9].*)\n \techo unsupported version\n exit 1\n ;;\n\tesac\n\nis a nonsense check.\n\nFor all released versions, people know how they looked like and we\ndo not have anything further to specify. Git 1.5.0 will forever\nidentify itself as:\n\n\t$ git version\n git version 1.5.0\n\nWorse yet, for an untagged version, you may get something like\n\n\tgit version 1.8.2.1-515-g78d2372\n\nand it may or may not behave the same way as 1.8.2.1 depending on\nwhat trait you are interested in.\n"},{"id":"214444","messageId":"99AE5E981E2547B6A71A4D77B17167B9@PhilipOakley","threadId":"33508","inReplyTo":"7vli8k4lnj.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH 0/2] Test the Git version string","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-04-16T07:25:24Z","receivedAt":"2013-04-16T07:25:24Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Junio C Hamano\" \nSent: Monday, April 15, 2013 2:39 AM\n> \"Philip Oakley\" writes:\n>\n>>> If the \"parsing\" is done for white/blacklist purposes, is there a\n>>> need to straight-jacket the verison string format like this series?\n>>\n>> The purpose is to document what we felt we could guarantee, and that\n>> which was open to variation, so that those, like the Git-Gui, can\n>> code\n>> in a sensible check for the version. Two digits (X.Y) should pass the\n>> existing Git Gui check.\n>>\n>> I'll drop the length limit, and keep to an X.Y check\n>>\n>> Is the end of t0000-basic.sh a sensible place for the check?\n>\n> Sorry, but I still do not understand what you are trying to achieve.\n>\n> What kind of benefit are you envisioning out of this?\n\nThe purpose of tests is to detect mistakes and spot regressions.\n\nA change to the 'git version X.Y.z' string would be a regression, as I \nspotted earlier, as it conflicts with expectations of standard \nprogrammes such as git-gui.\n\n>For a future\n> version, people would not know what incompatibilities it would\n> introduce, so\n>\n> case \"$(git version)\" in\n> \"git verison\"[2-9].*)\n> echo unsupported version\n> exit 1\n> ;;\n> esac\n>\n> is a nonsense check.\n>\n> For all released versions, people know how they looked like\n> and we\n> do not have anything further to specify. Git 1.5.0 will forever\n> identify itself as:\n>\n> $ git version\n> git version 1.5.0\n>\n> Worse yet, for an untagged version, you may get something like\n>\n> git version 1.8.2.1-515-g78d2372\n\nHowever, if it passes the test [all the tests], one expects it will be \nreasonably (almost completely) compatibility with external expectations, \nsuch as those of git gui.\n\nThe questions I'm posing is from the other direction - use of tests for \nquality control.\n\n>\n> and it may or may not behave the same way as 1.8.2.1 depending on\n> what trait you are interested in.\n\nThat will depend on the tests if [deliberately?] failed.\n\nI'll tidy up the patches and commit meesage and see how it looks then.\n\nPhilip\n"},{"id":"214511","messageId":"7v8v4imjji.fsf@alter.siamese.dyndns.org","threadId":"33508","inReplyTo":"99AE5E981E2547B6A71A4D77B17167B9@PhilipOakley","subject":"Re: [RFC/PATCH 0/2] Test the Git version string","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-16T18:12:33Z","receivedAt":"2013-04-16T18:12:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Philip Oakley\" writes:\n\n>> What kind of benefit are you envisioning out of this?\n>\n> The purpose of tests is to detect mistakes and spot regressions.\n>\n> A change to the 'git version X.Y.z' string would be a regression, as I\n> spotted earlier, as it conflicts with expectations of standard\n> programmes such as git-gui.\n\nSorry, but I do not follow.\n\nA released version says \"git version 1.8.2.1\". In a month or so,\nI'll have another one that says \"git version 1.8.3\". Or I may\ndecide to bump in preparation for 2.0 and it may identify itself as\n\"git version 1.9\".\n\nNeither of which no existing \"program such as git-gui\" has ever\nseen.\n\nIn what way is that a regression?\n"},{"id":"214515","messageId":"CAJDDKr7WKwt10sCRTbm8gdhwEUKSYuQxtPDVm7usTm2ZHryk9g@mail.gmail.com","threadId":"33508","inReplyTo":"7v8v4imjji.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH 0/2] Test the Git version string","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2013-04-16T18:24:28Z","receivedAt":"2013-04-16T18:24:28Z","isPatch":true,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Tue, Apr 16, 2013 at 11:12 AM, Junio C Hamano wrote:\n>\n> \"Philip Oakley\" writes:\n>\n> >> What kind of benefit are you envisioning out of this?\n> >\n> > The purpose of tests is to detect mistakes and spot regressions.\n> >\n> > A change to the 'git version X.Y.z' string would be a regression, as I\n> > spotted earlier, as it conflicts with expectations of standard\n> > programmes such as git-gui.\n>\n> Sorry, but I do not follow.\n>\n> A released version says \"git version 1.8.2.1\". In a month or so,\n> I'll have another one that says \"git version 1.8.3\". Or I may\n> decide to bump in preparation for 2.0 and it may identify itself as\n> \"git version 1.9\".\n>\n> Neither of which no existing \"program such as git-gui\" has ever\n> seen.\n>\n> In what way is that a regression?\n\nSorry. I was the one that first suggested that this was an issue.\n\nThe \"regression\" is that there are scripts and tools in the wild that\nneed to know the git version when deciding whether or not to use some\nnew feature.\n\ne.g. \"git status --ignore-submodules=dirty\" did not appear until git 1.7.2.\nA script may want to use this flag, but it will only want to use it\nwhen available.\n\nIf this string started saying \"The Git Version Control System v2.0\" then these\nscripts would be \"broken\" since they would no longer recognize this as a\n\"post-1.7.2 Git\".\n\nThe unstated suggestion here is that it may be helpful to others if we\nwere to declare that the \"git version\" output is plumbing.\n\nFolks are already using it that way so making it official would provide\na guarantee that we won't break them in the future.\n--\nDavid\n"},{"id":"214519","messageId":"7vip3ml2on.fsf@alter.siamese.dyndns.org","threadId":"33508","inReplyTo":"CAJDDKr7WKwt10sCRTbm8gdhwEUKSYuQxtPDVm7usTm2ZHryk9g@mail.gmail.com","subject":"Re: [RFC/PATCH 0/2] Test the Git version string","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-16T19:02:00Z","receivedAt":"2013-04-16T19:02:00Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Aguilar writes:\n\n> The \"regression\" is that there are scripts and tools in the wild that\n> need to know the git version when deciding whether or not to use some\n> new feature.\n>\n> e.g. \"git status --ignore-submodules=dirty\" did not appear until git 1.7.2.\n> A script may want to use this flag, but it will only want to use it\n> when available.\n>\n> If this string started saying \"The Git Version Control System v2.0\" then these\n> scripts would be \"broken\" since they would no longer recognize this as a\n> \"post-1.7.2 Git\".\n\nBlacklisting known-bad version and hoping all other versions\nincluding the ones you have never seen to behave in the way you\nexpect usually works but there is a limit.\n\nA change to say \"The Git Version Control System %s\" will not happen\nwilly-nilly, but when there is a good reason to do so, we would.\n\nI do not think a test that hardcodes the output is a good way to\nmake sure a change is being done with a good reason. After all, a\npatch that updates the \"git version %s\" string can just update the\nexpected output in the same patch. The only reason such a change\nwill be caught is because during the review, somebody notices that\nthe change touches the expected output of a test; for that to\nreliably protect the output, the test *has* to be commented to say\nthat this expected output should be changed very carefully.\n\nA much better solution would be to leave that \"very carefully\"\ncomment next to the in-code string to warn people about ramifiations\nof changing it.\n"},{"id":"214542","messageId":"2FE4D2171A03425AA9C8FF10140AC030@PhilipOakley","threadId":"33508","inReplyTo":"7v8v4imjji.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH 0/2] Test the Git version string","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2013-04-16T21:22:57Z","receivedAt":"2013-04-16T21:22:57Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Junio C Hamano\" \nSent: Tuesday, April 16, 2013 7:12 PM\n> \"Philip Oakley\" writes:\n>\n>>> What kind of benefit are you envisioning out of this?\n>>\n>> The purpose of tests is to detect mistakes and spot regressions.\n>>\n>> A change to the 'git version X.Y.z' string would be a regression, as \n>> I\n>> spotted earlier, as it conflicts with expectations of standard\n>> programmes such as git-gui.\n>\n> Sorry, but I do not follow.\n>\n> A released version says \"git version 1.8.2.1\". In a month or so,\n> I'll have another one that says \"git version 1.8.3\". Or I may\n> decide to bump in preparation for 2.0 and it may identify itself as\n> \"git version 1.9\".\n>\n> Neither of which no existing \"program such as git-gui\" has ever\n> seen.\n>\n> In what way is that a regression?\n\nBut they both pass the test and test suite, yes? And even if you use \ngit-gui with them, git-gui will not barf on start up, which it would if \nthe version string fails my test.\n\nPassing the test suite should be a reasonble guarantee that co-tools \nwill work, including those that check for version. This is a check for \nthat version string.\n\nHowever if someone[1] creates \"My Special Git Version 1-9-3 (Index \nV7b)\", and here I'm suggesting they may have other special changes, then \nthe version check will tell them that even when they have fixed their \nspecial changes to pass the other parts of the test suite, other \nco-tools could barf.\n\nIts about pushing the piece of string from the users end ;-) It also \nstops others trying to change 'git' to 'Git' within this message, just \nas I did.\n\nPhilip\n>\n[1] my first draft had 'you', but that is not a reasonable starting \nposition. It's more about *others* attempting to create release \nversions, which announce their name, that we expect to be compatible \nwith say git-gui (via the rest of the test suite), and need to check \nthat announcement. \n"}]}