{"thread":{"id":"44617","subject":"[RFC PATCH] GIT-VERSION-GEN: set --abbrev=9 to match auto-scaling","startedAt":"2016-12-04T20:46:09Z","lastAt":"2016-12-06T20:43:21Z","messageCount":12,"participants":["Ramsay Jones","Jeff King","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"306900","messageId":"22e9dfa0-47fb-d6fd-caf4-c2d87f63f707@ramsayjones.plus.com","threadId":"44617","inReplyTo":null,"subject":"[RFC PATCH] GIT-VERSION-GEN: set --abbrev=9 to match auto-scaling","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2016-12-04T20:45:59Z","receivedAt":"2016-12-04T20:46:09Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\nSigned-off-by: Ramsay Jones \n---\n\nHi Junio,\n\nI recently noticed that:\n\n $ make >pout 2>&1\n $ ./git version\n git version 2.11.0.286.g109e8a9\n $ git describe\n v2.11.0-286-g109e8a99d\n $\n\n... for non-release builds, the commit part of the version\nstring was still using an --abbrev=7.\n\nI don't know that it actually matters too much (since it will\nshow as many as necessary, thus the RFC), but it caused me to\nlook twice. ;-)\n\nATB,\nRamsay Jones\n\n GIT-VERSION-GEN | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN\nindex 520d6e66e..05601f753 100755\n--- a/GIT-VERSION-GEN\n+++ b/GIT-VERSION-GEN\n@@ -12,7 +12,7 @@ if test -f version\n then\n \tVN=$(cat version) || VN=\"$DEF_VER\"\n elif test -d ${GIT_DIR:-.git} -o -f .git &&\n-\tVN=$(git describe --match \"v[0-9]*\" --abbrev=7 HEAD 2>/dev/null) &&\n+\tVN=$(git describe --match \"v[0-9]*\" --abbrev=9 HEAD 2>/dev/null) &&\n \tcase \"$VN\" in\n \t*$LF*) (exit 1) ;;\n \tv[0-9]*)\n-- \n2.11.0\n"},{"id":"306909","messageId":"20161205053258.jtnqq64gp5n7vtni@sigill.intra.peff.net","threadId":"44617","inReplyTo":"22e9dfa0-47fb-d6fd-caf4-c2d87f63f707@ramsayjones.plus.com","subject":"Re: [RFC PATCH] GIT-VERSION-GEN: set --abbrev=9 to match auto-scaling","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-12-05T05:32:58Z","receivedAt":"2016-12-05T05:33:25Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Dec 04, 2016 at 08:45:59PM +0000, Ramsay Jones wrote:\n\n> \n> Signed-off-by: Ramsay Jones \n> ---\n> \n> Hi Junio,\n> \n> I recently noticed that:\n> \n> $ make >pout 2>&1\n> $ ./git version\n> git version 2.11.0.286.g109e8a9\n> $ git describe\n> v2.11.0-286-g109e8a99d\n> $\n> \n> ... for non-release builds, the commit part of the version\n> string was still using an --abbrev=7.\n\nIt seems like this kind of discussion ought to go in the commit message.\n:)\n\nThat said, I think the right patch may be to just drop --abbrev\nentirely. Its use goes all the way back to 9b88fcef7 (Makefile: use\ngit-describe to mark the git version., 2005-12-27), where it was\n--abbrev=4. That became --abbrev=7 in bf505158d (Git 1.7.10.1,\n2012-05-01) without further comment.\n\nI think at that point it was a noop, as 7 should have been the default.\nAnd now we probably ought to drop it, so that we can use the\nauto-scaling default.\n\n-Peff\n"},{"id":"306928","messageId":"ab1e7ce9-1022-0c72-2f72-63e3b9182bc9@ramsayjones.plus.com","threadId":"44617","inReplyTo":"20161205053258.jtnqq64gp5n7vtni@sigill.intra.peff.net","subject":"Re: [RFC PATCH] GIT-VERSION-GEN: set --abbrev=9 to match auto-scaling","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2016-12-05T11:21:14Z","receivedAt":"2016-12-05T11:22:43Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 05/12/16 05:32, Jeff King wrote:\n> On Sun, Dec 04, 2016 at 08:45:59PM +0000, Ramsay Jones wrote:\n>> I recently noticed that:\n>>\n>> $ make >pout 2>&1\n>> $ ./git version\n>> git version 2.11.0.286.g109e8a9\n>> $ git describe\n>> v2.11.0-286-g109e8a99d\n>> $\n>>\n>> ... for non-release builds, the commit part of the version\n>> string was still using an --abbrev=7.\n> \n> It seems like this kind of discussion ought to go in the commit message.\n> :)\n> \n> That said, I think the right patch may be to just drop --abbrev\n> entirely.\n\nHeh, that was the first version of the patch. However, I got to thinking\nabout why --abbrev=7 was there in the first place; the only reason I\ncould think of was to defeat local configuration to get a measure of\nreproducibility.\n\nUnfortunately, you can't get the 'auto' behaviour from --abbrev\n(on the pu branch):\n\n $ ./git describe --abbrev=-1\n v2.11.0-286-g109e8\n $ ./git describe --abbrev=0\n v2.11.0\n $ ./git describe\n v2.11.0-286-g109e8a99d\n $\n\nI did think about using '-c core.abbrev=auto', but that would\ndepend on Junio's patch (nothing wrong with that, of course):\n\n $ git version\n git version 2.11.0\n $ git -c core.abbrev=auto describe\n fatal: bad numeric config value 'auto' for 'core.abbrev': invalid unit\n $ ./git -c core.abbrev=auto describe\n v2.11.0-286-g109e8a99d\n $ \n\nWhat do you think?\n\nATB,\nRamsay Jones\n\n"},{"id":"306940","messageId":"xmqqbmwq5k7k.fsf@gitster.mtv.corp.google.com","threadId":"44617","inReplyTo":"20161205053258.jtnqq64gp5n7vtni@sigill.intra.peff.net","subject":"Re: [RFC PATCH] GIT-VERSION-GEN: set --abbrev=9 to match auto-scaling","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-12-05T18:01:19Z","receivedAt":"2016-12-05T18:01:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Sun, Dec 04, 2016 at 08:45:59PM +0000, Ramsay Jones wrote:\n>\n>> \n>> Signed-off-by: Ramsay Jones \n>> ---\n>> \n>> Hi Junio,\n>> \n>> I recently noticed that:\n>> \n>> $ make >pout 2>&1\n>> $ ./git version\n>> git version 2.11.0.286.g109e8a9\n>> $ git describe\n>> v2.11.0-286-g109e8a99d\n>> $\n>> \n>> ... for non-release builds, the commit part of the version\n>> string was still using an --abbrev=7.\n>\n> It seems like this kind of discussion ought to go in the commit message.\n> :)\n>\n> That said, I think the right patch may be to just drop --abbrev\n> entirely.\n> ...\n> I think at that point it was a noop, as 7 should have been the default.\n> And now we probably ought to drop it, so that we can use the\n> auto-scaling default.\n\nYeah, I agree.\n\nIt does mean that snapshot binaries built out of the same commit in\nthe same repository before and after a repack have higher chances of\ngetting named differently, which may surprise people, but that\nalready is possible with a fixed length if the repacking involves\npruning (albeit with lower probabilities), and I do not think it is\na problem.\n"},{"id":"306941","messageId":"xmqq7f7e5jsy.fsf@gitster.mtv.corp.google.com","threadId":"44617","inReplyTo":"ab1e7ce9-1022-0c72-2f72-63e3b9182bc9@ramsayjones.plus.com","subject":"Re: [RFC PATCH] GIT-VERSION-GEN: set --abbrev=9 to match auto-scaling","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-12-05T18:10:05Z","receivedAt":"2016-12-05T18:10:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramsay Jones writes:\n\n> Heh, that was the first version of the patch. However, I got to thinking\n> about why --abbrev=7 was there in the first place; the only reason I\n> could think of was to defeat local configuration to get a measure of\n> reproducibility.\n>\n> Unfortunately, you can't get the 'auto' behaviour from --abbrev\n> (on the pu branch):\n>\n> $ ./git describe --abbrev=-1\n> v2.11.0-286-g109e8\n> $ ./git describe --abbrev=0\n> v2.11.0\n> $ ./git describe\n> v2.11.0-286-g109e8a99d\n> $\n\nWhat is the reason why the last one is undesirable? Is it because\nthe user may have core.abbrev set to some value in the configuration\nand you want to override it to force \"auto\"?\n\nI am not sure how rigid GIT-VERSION-GEN wants to be to countermand\nsuch an explicit user preference (i.e. existing configuration).\n\n> I did think about using '-c core.abbrev=auto', \n\nHaving said that, if countermanding end-user's configuration is\ndesireble, I agree that \"-c core.abbrev=auto\" is the way to do so.\n\n> but that would depend on Junio's patch (nothing wrong with that,\n> of course):\n\nYou caught me. I'll need to polish that into a usable shape soon\nthen. And that is orthogonal to the \"does it make sense to force\n'auto' in this context?\" question.\n"},{"id":"306956","messageId":"e74163ee-e7d4-bcbd-e65f-368bc2ee9a2d@ramsayjones.plus.com","threadId":"44617","inReplyTo":"xmqq7f7e5jsy.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC PATCH] GIT-VERSION-GEN: set --abbrev=9 to match auto-scaling","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2016-12-05T20:30:17Z","receivedAt":"2016-12-05T20:31:09Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 05/12/16 18:10, Junio C Hamano wrote:\n> Ramsay Jones writes:\n> \n>> Heh, that was the first version of the patch. However, I got to thinking\n>> about why --abbrev=7 was there in the first place; the only reason I\n>> could think of was to defeat local configuration to get a measure of\n>> reproducibility.\n>>\n>> Unfortunately, you can't get the 'auto' behaviour from --abbrev\n>> (on the pu branch):\n>>\n>> $ ./git describe --abbrev=-1\n>> v2.11.0-286-g109e8\n>> $ ./git describe --abbrev=0\n>> v2.11.0\n>> $ ./git describe\n>> v2.11.0-286-g109e8a99d\n>> $\n> \n> What is the reason why the last one is undesirable? Is it because\n> the user may have core.abbrev set to some value in the configuration\n> and you want to override it to force \"auto\"?\n\nAs I said, the original version of the patch just removed the\n--abbrev=7, but then I started to think about why you might have\nused --abbrev in the first place (first in commit 9b88fcef7 and\nagain in commit bf505158d). Making sure to override the configuration\nwas the only thing I could come up with. So, I was hoping you could\nremember why! :-P\n\n(I assumed it was to force a measure of uniformity/reproducibility).\n\nATB,\nRamsay Jones\n\n\n"},{"id":"306972","messageId":"xmqqr35m2eva.fsf@gitster.mtv.corp.google.com","threadId":"44617","inReplyTo":"e74163ee-e7d4-bcbd-e65f-368bc2ee9a2d@ramsayjones.plus.com","subject":"Re: [RFC PATCH] GIT-VERSION-GEN: set --abbrev=9 to match auto-scaling","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-12-05T22:24:57Z","receivedAt":"2016-12-05T22:25:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramsay Jones writes:\n\n> As I said, the original version of the patch just removed the\n> --abbrev=7, but then I started to think about why you might have\n> used --abbrev in the first place (first in commit 9b88fcef7 and\n> again in commit bf505158d). Making sure to override the configuration\n> was the only thing I could come up with. So, I was hoping you could\n> remember why! :-P\n\nNope. As a maintainer support script, the only thing I cared about\nit is that there is no -gXXXX at the end for anything I release ;-)\n\n> (I assumed it was to force a measure of uniformity/reproducibility).\n\nYou cannot force uniformity/reproducibility with fixed abbrev,\nunless you set abbreviation length to 40, so you are correct to add\n\"a measure of\" there ;-) The first choice (i.e. 4) may have had a\njustification to force absolute minimum, and the second one (i.e. 7)\nmay have had a justifiation to make it clear that we are using the\nsame setting as the default, so in post-1.7.10 era, I think it is\nfine for us to just say \"we have been using the same as default, so\nlet's not specify anything explicitly\".\n\n\n"},{"id":"306975","messageId":"cbb39f75-dc3b-6bc7-9c60-9ce4e7d225f7@ramsayjones.plus.com","threadId":"44617","inReplyTo":"xmqqr35m2eva.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC PATCH] GIT-VERSION-GEN: set --abbrev=9 to match auto-scaling","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2016-12-05T22:42:57Z","receivedAt":"2016-12-05T22:43:21Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 05/12/16 22:24, Junio C Hamano wrote:\n> Ramsay Jones writes:\n> \n>> As I said, the original version of the patch just removed the\n>> --abbrev=7, but then I started to think about why you might have\n>> used --abbrev in the first place (first in commit 9b88fcef7 and\n>> again in commit bf505158d). Making sure to override the configuration\n>> was the only thing I could come up with. So, I was hoping you could\n>> remember why! :-P\n> \n> Nope. As a maintainer support script, the only thing I cared about\n> it is that there is no -gXXXX at the end for anything I release ;-)\n> \n>> (I assumed it was to force a measure of uniformity/reproducibility).\n> \n> You cannot force uniformity/reproducibility with fixed abbrev,\n> unless you set abbreviation length to 40, so you are correct to add\n> \"a measure of\" there ;-)\n\nIndeed. ;-)\n\n> The first choice (i.e. 4) may have had a\n> justification to force absolute minimum, and the second one (i.e. 7)\n> may have had a justifiation to make it clear that we are using the\n> same setting as the default, so in post-1.7.10 era, I think it is\n> fine for us to just say \"we have been using the same as default, so\n> let's not specify anything explicitly\".\n\nSo, you would be happy with just removing the '--abbrev' argument?\n\n(That's fine by me; I don't set core.abbrev!)\n\nATB,\nRamsay Jones\n\n"},{"id":"307008","messageId":"20161206140259.lly76xkvsj7su3om@sigill.intra.peff.net","threadId":"44617","inReplyTo":"xmqqbmwq5k7k.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC PATCH] GIT-VERSION-GEN: set --abbrev=9 to match auto-scaling","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-12-06T14:03:00Z","receivedAt":"2016-12-06T14:03:23Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Dec 05, 2016 at 10:01:19AM -0800, Junio C Hamano wrote:\n\n> > That said, I think the right patch may be to just drop --abbrev\n> > entirely.\n> > ...\n> > I think at that point it was a noop, as 7 should have been the default.\n> > And now we probably ought to drop it, so that we can use the\n> > auto-scaling default.\n> \n> Yeah, I agree.\n> \n> It does mean that snapshot binaries built out of the same commit in\n> the same repository before and after a repack have higher chances of\n> getting named differently, which may surprise people, but that\n> already is possible with a fixed length if the repacking involves\n> pruning (albeit with lower probabilities), and I do not think it is\n> a problem.\n\nI think that the number is already unstable, even with --abbrev, as it\njust specifies a minimum. So any operation that creates objects has a\npossibility of increasing the length. Or more likely, two people\ndescribing the same version may end up with different strings because\nthey have different objects in their repositories (e.g., I used to\ncarry's trast's git-notes archive of the mailing list which added quite\na few objects).\n\nI agree that having it change over the course of a repack is slightly\n_more_ surprising than those cases, but ultimately the value just isn't\nstable.\n\n-Peff\n"},{"id":"307023","messageId":"xmqqwpfc2a7g.fsf@gitster.mtv.corp.google.com","threadId":"44617","inReplyTo":"20161206140259.lly76xkvsj7su3om@sigill.intra.peff.net","subject":"Re: [RFC PATCH] GIT-VERSION-GEN: set --abbrev=9 to match auto-scaling","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-12-06T18:17:55Z","receivedAt":"2016-12-06T18:18:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Mon, Dec 05, 2016 at 10:01:19AM -0800, Junio C Hamano wrote:\n>\n>> > That said, I think the right patch may be to just drop --abbrev\n>> > entirely.\n>> > ...\n>> > I think at that point it was a noop, as 7 should have been the default.\n>> > And now we probably ought to drop it, so that we can use the\n>> > auto-scaling default.\n>> \n>> Yeah, I agree.\n>> \n>> It does mean that snapshot binaries built out of the same commit in\n>> the same repository before and after a repack have higher chances of\n>> getting named differently, which may surprise people, but that\n>> already is possible with a fixed length if the repacking involves\n>> pruning (albeit with lower probabilities), and I do not think it is\n>> a problem.\n>\n> I think that the number is already unstable, even with --abbrev, as it\n> just specifies a minimum. So any operation that creates objects has a\n> possibility of increasing the length. Or more likely, two people\n> describing the same version may end up with different strings because\n> they have different objects in their repositories (e.g., I used to\n> carry's trast's git-notes archive of the mailing list which added quite\n> a few objects).\n>\n> I agree that having it change over the course of a repack is slightly\n> _more_ surprising than those cases, but ultimately the value just isn't\n> stable.\n\nYup, that is what I meant to say with \"that is already possible\" and\nwe are on the same page. As all three of us seem to be happy with\njust dropping --abbrev and letting describe do its default thing (as\nconfigured by whoever is doing the build), let's do so.\n\n-- >8 --\nFrom: Ramsay Jones \nDate: Sun, 4 Dec 2016 20:45:59 +0000\nSubject: [PATCH] GIT-VERSION-GEN: do not force abbreviation length used by 'describe'\n\nThe default version name for a Git binary is computed by running\n\"git describe\" on the commit the binary is made out of, basing on a\ntag whose name matches \"v[0-9]*\", e.g. v2.11.0-rc2-2-g7f1dc9.\n\nIn the very early days, with 9b88fcef7d (\"Makefile: use git-describe\nto mark the git version.\", 2005-12-27), we used \"--abbrev=4\" to get\nabsolute minimum number of abbreviated commit object name. This was\nlater changed to match the default minimum of 7 with bf505158d0\n(\"Git 1.7.10.1\", 2012-05-01).\n\nThese days, the \"default minimum\" scales automatically depending on\nthe size of the repository, and there is no point in specifying a\nparticular abbreviation length; all we wanted since Git 1.7.10.1\ndays was to get \"something reasonable we would use by default\".\n\nJust drop \"--abbrev=\" from the invocation of \"git describe\"\nand let the command pick what it thinks is appropriate, taking the\nend user's configuration and the repository contents into account.\n\nSigned-off-by: Ramsay Jones \nHelped-by: Jeff King \nSigned-off-by: Junio C Hamano \n---\n GIT-VERSION-GEN | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN\nindex 556fbfc104..f95b04bb36 100755\n--- a/GIT-VERSION-GEN\n+++ b/GIT-VERSION-GEN\n@@ -12,7 +12,7 @@ if test -f version\n then\n \tVN=$(cat version) || VN=\"$DEF_VER\"\n elif test -d ${GIT_DIR:-.git} -o -f .git &&\n-\tVN=$(git describe --match \"v[0-9]*\" --abbrev=7 HEAD 2>/dev/null) &&\n+\tVN=$(git describe --match \"v[0-9]*\" HEAD 2>/dev/null) &&\n \tcase \"$VN\" in\n \t*$LF*) (exit 1) ;;\n \tv[0-9]*)\n-- \n2.11.0-263-gd89495280e\n\n"},{"id":"307031","messageId":"20161206182648.sxoftkd4hjhvenaf@sigill.intra.peff.net","threadId":"44617","inReplyTo":"xmqqwpfc2a7g.fsf@gitster.mtv.corp.google.com","subject":"Re: [RFC PATCH] GIT-VERSION-GEN: set --abbrev=9 to match auto-scaling","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-12-06T18:26:48Z","receivedAt":"2016-12-06T18:27:00Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Dec 06, 2016 at 10:17:55AM -0800, Junio C Hamano wrote:\n\n> Yup, that is what I meant to say with \"that is already possible\" and\n> we are on the same page. As all three of us seem to be happy with\n> just dropping --abbrev and letting describe do its default thing (as\n> configured by whoever is doing the build), let's do so.\n> \n> -- >8 --\n> From: Ramsay Jones \n> Date: Sun, 4 Dec 2016 20:45:59 +0000\n> Subject: [PATCH] GIT-VERSION-GEN: do not force abbreviation length used by 'describe'\n\nThanks, this is a nice summary of the discussion, and the patch is\nobviously correct.\n\n-Peff\n"},{"id":"307048","messageId":"2435294e-9852-d215-0a9c-a73a2b522ff2@ramsayjones.plus.com","threadId":"44617","inReplyTo":"20161206182648.sxoftkd4hjhvenaf@sigill.intra.peff.net","subject":"Re: [RFC PATCH] GIT-VERSION-GEN: set --abbrev=9 to match auto-scaling","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2016-12-06T20:43:13Z","receivedAt":"2016-12-06T20:43:21Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 06/12/16 18:26, Jeff King wrote:\n> On Tue, Dec 06, 2016 at 10:17:55AM -0800, Junio C Hamano wrote:\n> \n>> Yup, that is what I meant to say with \"that is already possible\" and\n>> we are on the same page. As all three of us seem to be happy with\n>> just dropping --abbrev and letting describe do its default thing (as\n>> configured by whoever is doing the build), let's do so.\n>>\n>> -- >8 --\n>> From: Ramsay Jones \n>> Date: Sun, 4 Dec 2016 20:45:59 +0000\n>> Subject: [PATCH] GIT-VERSION-GEN: do not force abbreviation length used by 'describe'\n> \n> Thanks, this is a nice summary of the discussion, and the patch is\n> obviously correct.\n\nYep, looks very good to me! (I had started to write a commit\nmessage for this patch, when your email arrived. Needless to\nsay, but your message is much better than mine!)\n\nThanks!\n\nATB,\nRamsay Jones\n\n"}]}