git describe shows the wrong thing

[cwgoes]

git describe

v0.18.0-rc0-608-g23e3d5ac

git describe --tags is more accurate.

cc @alessio

[alessio]

Apparently develop does not contain the most recent tags:

alessio@bizet:~/.../github.com/cosmos/cosmos-sdk$ git branch
  alessio/1632-examples-simple-integration-tests
* develop
  master
alessio@bizet:~/.../github.com/cosmos/cosmos-sdk$ git branch --contains tags/v0.23.1
  master
alessio@bizet:~/.../github.com/cosmos/cosmos-sdk$ git branch --contains tags/v0.23.0
  master

It makes sense in the context of git flow to not merge tags back to develop, though it'd be nice to achieve a numeric versioning scheme for unreleased develop builds. It's quite a common practice in Debian to rely on git describe to package upstream git snapshots, its output format follows:

<most recent tag>-<# of commits since most recent tag>-g<short hash>

This allows one to introduce a monotically increasing component before the commit hash. It'd be quite easy too to modify the Makefile's COMMIT_HASH variable and handle the command's output appropriately.

[ValarDragon]

Do we achieve this by merging tagged releases back into develop?

[alessio]

Yes, correct. We need to merge the tags back to develop

[alexanderbez]

@alessio what will this achieve for us that is currently a pain point or what benefits will it provide us?

[alessio]

@alexanderbez:

alessio@bizet:~/.../github.com/cosmos/cosmos-sdk$ gaiacli version
0.24.2-461261a3

If we could rely on git describe we would have a consistent numeric versioning scheme, e.g.:

alessio@bizet:~/.../github.com/cosmos/cosmos-sdk$ gaiacli version
0.24.2-397-g461261a3

[ValarDragon]

Merging the tagged release back into develop seems reasonable / like something we can do.

[ebuchman]

We should always be merging tagged releases back to develop as part of gitflow.