git describe --always doesn't show the current tag

[laurrentt]

I've been looking for way to use my git tags as serverless variables and your project seemed like the perfect match. Although I'm still not able to get tag to show up, only the git sha.

I'm using ${git:describe} and I think it was expected that it showed the tag, at least according to the latest release note:

git describe now uses --always, so if there are not tags it returns a hash instead of failing (Thanks to @e-e-e)

In my experience to display the tag you had to add the --tags after --always in order to show the current tag you're on. I thought maybe it was macOS specific, however I tried on Ubuntu with the same result.

Would it be possible to add the --tags to the git describe command? I could obviously do a PR but I want to make sure I'm not mistaken first.

[jacob-meacham]

Hi @laurrentt thanks for the report - however, I'm not seeing the behavior you're describing on my mac -
In a repo with tags

$ git checkout master
$ git describe --always
3.0.0
$ git checkout develop
$ git describe --always
3.0.0-2-g175974e

In a repo without tags:

$ git describe --always
df57d9d

This could possibly be caused by a git version mismatch - I'm running git version 2.15.1. Thanks!

[laurrentt]

Hi @jacob-meacham, thx for taking the time to reply to my issue 😄

I've found why we don't have the same output with the same command here: https://stackoverflow.com/a/4154518/970247. In short, I'm using GitHub releases to create my tags. It creates lightweight tags (instead of annotated ones) which can't be seen with only git describe --always, it needs the --tags to consider lightweights tags.

I think adding the --tags flag would not change the actual behaviour for annotated tags but would allow me to get the proper output with GitHub created tags.

What do you think?

[jacob-meacham]

@laurrentt this change will potentially alter behavior for others (if they're using both light and annotated tags) - can we hide it behind a flag (default off) for now? When I next make a breaking release, I'll change the flag to default true.

Thanks!

[laurrentt]

Yes you're absolutely right, I didn't think it through. I think considering this, even after making a breaking change, this could still be a problem for current users. Would you consider making a new variable called something like lightweightTag that would execute git describe --always --tags?

Thanks again for taking the time to answer

[jacob-meacham]

I think I'd prefer adding a config point for this instead of a different git variable - for a particular project, it seems unlikely to me that someone would want both behaviors. So something like:

custom:
gitConsiderLightweightTags: true

and then default it to false

[domroutley]

Hey, I also use lightweight tags, being able to visually grep my functions by Github releases/tags would be really useful.
The output of git describe --always --tags (combined with the branch name) is what I want in the function description.

Both having a lightweightTag variable or a toggle between lightweight and annotated tags would work.
However the variable would enable people to use both annotated and lightweight tags if they wished.

@jacob-meacham would you have a problem with me opening a PR to implement the lightweightTag variable?

[jacob-meacham]

@domroutley nope, that sounds excellent!