{"thread":{"id":"10618","subject":"why the 'g' prefix on the SHA1 in git-describe output?","startedAt":"2007-11-03T12:25:26Z","lastAt":"2007-11-03T16:10:43Z","messageCount":4,"participants":["Jim Meyering","Lars Hjemli","Andreas Ericsson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"58119","messageId":"871wb7a53d.fsf@rho.meyering.net","threadId":"10618","inReplyTo":null,"subject":"why the 'g' prefix on the SHA1 in git-describe output?","fromName":"Jim Meyering","fromEmail":"jim@meyering.net","sentAt":"2007-11-03T12:25:26Z","receivedAt":"2007-11-03T12:25:26Z","isPatch":false,"sender":{"key":"jim@meyering.net","avatar":"https://avatars.githubusercontent.com/u/710630?v=4"},"body":"Hello,\n\nCan anyone tell me what motivated adding the 'g' prefix on the SHA1 in\ngit-describe output? Is there some version-parsing/comparing tool that\nmisbehaves on a component like the SHA1 that would otherwise start with a\ndigit but contain non-numeric bytes, too?\n\nWhy do I ask? Because I'm using a bastardized version of GIT-VERSION-GEN\nin coreutils' build-aux/git-version-gen, and removed the 'g' to shorten\nthe string by a byte. If there's a good reason (i.e., other than vanity :-)\nfor the 'g', I'll propose comments for GIT-VERSION-GEN, so others\ndon't do what I've done.\n\nJim\n"},{"id":"58133","messageId":"8c5c35580711030656h23d5910ah824de41a2cf4eafe@mail.gmail.com","threadId":"10618","inReplyTo":"871wb7a53d.fsf@rho.meyering.net","subject":"Re: why the 'g' prefix on the SHA1 in git-describe output?","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-11-03T13:56:47Z","receivedAt":"2007-11-03T13:56:47Z","isPatch":false,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On Nov 3, 2007 1:25 PM, Jim Meyering wrote:\n> Can anyone tell me what motivated adding the 'g' prefix on the SHA1 in\n> git-describe output?\n\nI'm not sure what _motivated_ the 'g', but currently git-rev-parse\nunderstands the output from git-describe _if_ the 'g' is present.\n\n--\nlarsh\n"},{"id":"58145","messageId":"472C915E.8070205@op5.se","threadId":"10618","inReplyTo":"8c5c35580711030656h23d5910ah824de41a2cf4eafe@mail.gmail.com","subject":"Re: why the 'g' prefix on the SHA1 in git-describe output?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-11-03T15:18:54Z","receivedAt":"2007-11-03T15:18:54Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Lars Hjemli wrote:\n> On Nov 3, 2007 1:25 PM, Jim Meyering wrote:\n>> Can anyone tell me what motivated adding the 'g' prefix on the SHA1 in\n>> git-describe output?\n> \n> I'm not sure what _motivated_ the 'g', but currently git-rev-parse\n> understands the output from git-describe _if_ the 'g' is present.\n> \n\nIt's been there since 908e5310b958619559d34b0b6da122f058faa47e, which\nhas the commit-subject 'Add a \"git-describe\" command'.\n\nI think it'd be more trouble removing it now than it is to keep it,\nsince a lot of script depend on it being there for parsing out\nversioning info in various autobuild- and release scripts.\n\nIf you want to change it, I'd suggest adding a \"--no-sha1\" option\nthat makes the entire \"-g%s\" part of the output go away, or\nperhaps adding a --format=\"%v-%d-%g\" (for the default behaviour).\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"58153","messageId":"87ir4j71j0.fsf@rho.meyering.net","threadId":"10618","inReplyTo":"472C915E.8070205@op5.se","subject":"Re: why the 'g' prefix on the SHA1 in git-describe output?","fromName":"Jim Meyering","fromEmail":"jim@meyering.net","sentAt":"2007-11-03T16:10:43Z","receivedAt":"2007-11-03T16:10:43Z","isPatch":false,"sender":{"key":"jim@meyering.net","avatar":"https://avatars.githubusercontent.com/u/710630?v=4"},"body":"Andreas Ericsson wrote:\n> Lars Hjemli wrote:\n>> On Nov 3, 2007 1:25 PM, Jim Meyering wrote:\n>>> Can anyone tell me what motivated adding the 'g' prefix on the SHA1 in\n>>> git-describe output?\n>>\n>> I'm not sure what _motivated_ the 'g', but currently git-rev-parse\n>> understands the output from git-describe _if_ the 'g' is present.\n>>\n>\n> It's been there since 908e5310b958619559d34b0b6da122f058faa47e, which\n> has the commit-subject 'Add a \"git-describe\" command'.\n>\n> I think it'd be more trouble removing it now than it is to keep it,\n> since a lot of script depend on it being there for parsing out\n> versioning info in various autobuild- and release scripts.\n>\n> If you want to change it, I'd suggest adding a \"--no-sha1\" option\n> that makes the entire \"-g%s\" part of the output go away, or\n> perhaps adding a --format=\"%v-%d-%g\" (for the default behaviour).\n\nThanks to both of you for the feedback.\nFYI, I didn't propose to change it in git.\n\nI was wondering whether to restore the 'g' in snapshot version\nnumbers for coreutils, autoconf, etc.:\n\n http://thread.gmane.org/gmane.comp.sysutils.autoconf.general/9784/focus=9811\n\nSince coreutils version strings will end up having at least one more \".\"\n(currently they look like this: 6.9-375-3e3f8), that means transforming\na version string into input for git-rev-parse will require the reverse\nxform. Once you're doing some transformation, an additional one to\ninsert the required 'g' is no big deal, so I expect to continue omitting\nthe 'g' from version strings: makes file names 1 byte shorter.\n"}]}