threads / discuss / 10618

why the 'g' prefix on the SHA1 in git-describe output?

Subject: why the 'g' prefix on the SHA1 in git-describe output?

## tl;dr

4 messages between Nov 3, 2007 and Nov 3, 2007.

replies: 3people: 3as markdown or json

Jim Meyering· Nov 3, 2007, 12:25 UTC · lore

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· Nov 3, 2007, 13:56 UTC · re: Jim Meyering · lore

Re: why the 'g' prefix on the SHA1 in git-describe output?

On Nov 3, 2007 1:25 PM, Jim Meyering <jim@meyering.net> 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· Nov 3, 2007, 15:18 UTC · re: Lars Hjemli · lore

Re: why the 'g' prefix on the SHA1 in git-describe output?

Lars Hjemli wrote:

Show 7 quoted lines

> On Nov 3, 2007 1:25 PM, Jim Meyering <jim@meyering.net> 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· Nov 3, 2007, 16:10 UTC · re: Andreas Ericsson · lore

Re: why the 'g' prefix on the SHA1 in git-describe output?

Andreas Ericsson <ae@op5.se> wrote:

Show 19 quoted lines

> Lars Hjemli wrote:
>> On Nov 3, 2007 1:25 PM, Jim Meyering <jim@meyering.net> 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.