# why the 'g' prefix on the SHA1 in git-describe output? 4 messages from 2007-11-03 to 2007-11-03. Participants: Jim Meyering, Lars Hjemli, Andreas Ericsson. Thread: https://gitlist.dev/t/10618 ## Jim Meyering, 2007-11-03 12:25 Subject: why the 'g' prefix on the SHA1 in git-describe output? Message-ID: <871wb7a53d.fsf@rho.meyering.net> URL: https://gitlist.dev/e/871wb7a53d.fsf%40rho.meyering.net ``` Hello, Can anyone tell me what motivated adding the 'g' prefix on the SHA1 in git-describe output? Is there some version-parsing/comparing tool that misbehaves on a component like the SHA1 that would otherwise start with a digit but contain non-numeric bytes, too? Why do I ask? Because I'm using a bastardized version of GIT-VERSION-GEN in coreutils' build-aux/git-version-gen, and removed the 'g' to shorten the string by a byte. If there's a good reason (i.e., other than vanity :-) for the 'g', I'll propose comments for GIT-VERSION-GEN, so others don't do what I've done. Jim ``` ## Lars Hjemli, 2007-11-03 13:56 Subject: Re: why the 'g' prefix on the SHA1 in git-describe output? Message-ID: <8c5c35580711030656h23d5910ah824de41a2cf4eafe@mail.gmail.com> URL: https://gitlist.dev/e/8c5c35580711030656h23d5910ah824de41a2cf4eafe%40mail.gmail.com In-Reply-To: <871wb7a53d.fsf@rho.meyering.net> ``` On Nov 3, 2007 1:25 PM, Jim Meyering wrote: > Can anyone tell me what motivated adding the 'g' prefix on the SHA1 in > git-describe output? I'm not sure what _motivated_ the 'g', but currently git-rev-parse understands the output from git-describe _if_ the 'g' is present. -- larsh ``` ## Andreas Ericsson, 2007-11-03 15:18 Subject: Re: why the 'g' prefix on the SHA1 in git-describe output? Message-ID: <472C915E.8070205@op5.se> URL: https://gitlist.dev/e/472C915E.8070205%40op5.se In-Reply-To: <8c5c35580711030656h23d5910ah824de41a2cf4eafe@mail.gmail.com> ``` Lars Hjemli wrote: > On Nov 3, 2007 1:25 PM, Jim Meyering wrote: >> Can anyone tell me what motivated adding the 'g' prefix on the SHA1 in >> git-describe output? > > I'm not sure what _motivated_ the 'g', but currently git-rev-parse > understands the output from git-describe _if_ the 'g' is present. > It's been there since 908e5310b958619559d34b0b6da122f058faa47e, which has the commit-subject 'Add a "git-describe" command'. I think it'd be more trouble removing it now than it is to keep it, since a lot of script depend on it being there for parsing out versioning info in various autobuild- and release scripts. If you want to change it, I'd suggest adding a "--no-sha1" option that makes the entire "-g%s" part of the output go away, or perhaps adding a --format="%v-%d-%g" (for the default behaviour). -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 ``` ## Jim Meyering, 2007-11-03 16:10 Subject: Re: why the 'g' prefix on the SHA1 in git-describe output? Message-ID: <87ir4j71j0.fsf@rho.meyering.net> URL: https://gitlist.dev/e/87ir4j71j0.fsf%40rho.meyering.net In-Reply-To: <472C915E.8070205@op5.se> ``` Andreas Ericsson wrote: > Lars Hjemli wrote: >> On Nov 3, 2007 1:25 PM, Jim Meyering wrote: >>> Can anyone tell me what motivated adding the 'g' prefix on the SHA1 in >>> git-describe output? >> >> I'm not sure what _motivated_ the 'g', but currently git-rev-parse >> understands the output from git-describe _if_ the 'g' is present. >> > > It's been there since 908e5310b958619559d34b0b6da122f058faa47e, which > has the commit-subject 'Add a "git-describe" command'. > > I think it'd be more trouble removing it now than it is to keep it, > since a lot of script depend on it being there for parsing out > versioning info in various autobuild- and release scripts. > > If you want to change it, I'd suggest adding a "--no-sha1" option > that makes the entire "-g%s" part of the output go away, or > perhaps adding a --format="%v-%d-%g" (for the default behaviour). Thanks to both of you for the feedback. FYI, I didn't propose to change it in git. I was wondering whether to restore the 'g' in snapshot version numbers for coreutils, autoconf, etc.: http://thread.gmane.org/gmane.comp.sysutils.autoconf.general/9784/focus=9811 Since coreutils version strings will end up having at least one more "." (currently they look like this: 6.9-375-3e3f8), that means transforming a version string into input for git-rev-parse will require the reverse xform. Once you're doing some transformation, an additional one to insert the required 'g' is no big deal, so I expect to continue omitting the 'g' from version strings: makes file names 1 byte shorter. ```