search

tvdstaaij / node-git-describe

Git describe information at runtime, with semver support
36 stars 5 forks source link

The hash is not prefixed with `g` #30

Open agross opened 1 year ago

agross commented 1 year ago

Contrary to what the documentation states the hash value is not (always?) prefixed with a g.

In https://github.com/tvdstaaij/node-git-describe/issues/6#issuecomment-267847367 it was discussed that git describe (the command) prepends g to the hash, but this is actually not the case.

$ git log --oneline -1
d4ec867 (HEAD -> pact, origin/pact) ...

$ git describe --always
d4ec867

git describe (the command) will only prepend the g if a tag was found and HEAD does not point to the nearest tag.

I'm reporting here because of https://github.com/absolute-version/absolute-version-js/issues/3

TimothyJones commented 1 year ago

Thanks for this.

A clarification: I can't see in the documentation for node-git-describe where it says that the hash value always has a g prefix - are you saying that the example implies that this is the case, or have I missed a part in the documentation?

Anyway, I think the problem here is that because --always is always used (heh), it's not always a wrapper for the <describeOutput> format you linked, which says:

Output from git describe; i.e. a closest tag, optionally followed by a dash and a number of commits, followed by a dash, a g, and an abbreviated object name.

However, the output from git-describe doesn't always match that format - the documentation for --always says:

Show uniquely abbreviated commit object as fallback.

which would not include the g, of course.

I'm not sure what the right fix here is. I like the rationale in #6 where node-git-describe just repeats the git-describe output. But with --always, we're no longer getting <describeOutput> output if there aren't any tags. I think the two options are:

  1. Add a g if it is missing (this is the option that prioritises a consistent format for the hash field, but would be a breaking change), or
  2. Add a clarification in the README explaining that --always is used for the git-describe call, and so g may or may not be present (this is the option that prioritises matching the output from git-describe as close as possible).

I have a slight preference for option 2, as it fits with the rationale in #6 where this package just wraps git-describe (which I agree with).

What do you think?