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

Andreas Ericsson [off-list ref] wrote:

Lars Hjemli wrote:

quoted

On Nov 3, 2007 1:25 PM, Jim Meyering [off-list ref] wrote:

quoted

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.