use long git tag as default version

[fogfish]

This is a question about rebar v 3.9.0 behaviour on auto assignment of app version based on git tag.

Current behaviour

The app.src uses a git version

{application, xxx,
   [
      {vsn,         "git"},
      ...

which is replace by rebar3 to

{application, xxx,
   [
      {vsn,         "2.0.7+build.110.refc70120b"},
      ...

https://github.com/erlang/rebar3/blob/master/src/rebar_git_resource.erl#L269

Expected behaviour

The usage of git describe --tags --long gives a nice, shorter and still lexicographically ordered version e.g. 2.0.7-1-gc70120b

Whould it make sense to start using it instead of current combination?

git -c color.ui=false log --oneline --no-walk --tags --decorate
git log -n 1 --pretty=format:\"%h\n\" 
git rev-list HEAD

[tsloughter]

I don't remember why the format we use is used. Is --tags --long "recent" (newer than like 5 years ago)?

[fogfish]

Hard to say... I am using git describe --tags --long for really looong time. Event git 2.4.6 has it, it was shipped in 2015.

[fogfish]

I am fine to make PR to this issue, if you are fine to use git describe --tags --long !?

[ferd]

2015 is not very recent by git standards considering when we initially made the decision to support that stuff. Back when we started, we had some bug issues about people whose CentOS builds were stuck on 1.7.x versions of git from 2013 or prior and would even cause issues with shallow cloning of deps :)

One thing to be careful about is that the hg resource handling we do does the same kind of stuff. The version provided is not just the tag, but the distance from the latest tag. So for example 2.0.7+build.110.refc70120b does not just tell you the hash, it tells you you're 110 commits after tag 2.7.0, and then specifies the ref c70120b.

If I recall, at the time it felt more informative than just giving a hash, it also gave an idea of some logical time lapse between the last cut release.

[fogfish]

The version provided is not just the tag, but the distance from the latest tag.

This is exactly what git describe --tags --long does

1.0.5-2-gad0b2fb

As you can see, it just eliminates build and ref terms from string.

All-in-all this is your call, if you want to switch to this feature of git. I can help!