Code review comment for ~nicolasbock/git-build-recipe:long

It's generally a mistake (though a very tempting one) to put git commit IDs in package version numbers, which is what this would do. Git commit IDs aren't ordered in the sense of Debian version comparison. Now, `git describe --tags --abbrev=7` does include the number of commits on top of the latest tag, which mitigates that problem; but the commit ID part is rather unusable.

There's also a non-obvious syntactic problem here. `git describe --tags --abbrev=7` outputs something like "2.11.2-16-gf6fbdf8". But in a Debian version, the "Debian revision" part of the version is defined as the part to the right of the _rightmost_ "-" character (see https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-version); that means that a package using such a version would parse as having an upstream version of "2.11.2-16" and a Debian revision of "gf6fbdf8", which is unlikely to be quite correct and which can cause subtle problems.

I recommend instead using some form of the `{revno}` variable (perhaps in addition to `{latest-tag}`) to build up the version of your recipe. This gives you something that fulfils the same purpose as the usable part of `git describe --tags --abbrev=7`, but without the confusing pitfalls. Have you tried that?