On Sun, May 19, 2013 at 06:07:07AM -0400, Alon Bar-Lev wrote:
I believe git magic should not be used in source[1]
I don't see how git describe is unsuitable for this. From the examples section of the manpage[1]:
<<<EOF
With something like git.git current tree, I get:
[torvalds@g5 git]$ git describe parent v1.0.4-14-g2414721
i.e. the current head of my "parent" branch is based on v1.0.4, but since it has a few commits on top of that, describe has added the number of additional commits ("14") and an abbreviated object name for the commit itself ("2414721") at the end.
The number of additional commits is the number of commits which would be displayed by "git log v1.0.4..parent". The hash suffix is "-g" + 7-char abbreviation for the tip commit of parent (which was 2414721b194453f058079d897d13c4e377f92dc6). The "g" prefix stands for "git" and is used to allow describing the version of a software depending on the SCM the software is managed with. This is useful in an environment where people may use different SCMs.
Doing a git describe on a tag-name will just show the tag name:
[torvalds@g5 git]$ git describe v1.0.4 v1.0.4
EOF
Using this I think you can get consistent nightly build versioning. The only downside I see is that you have to put the number of commits + hash in the release so you can't bump when you change the spec file. This isn't a problem since the spec file is included in git so any change will be a commit, thus increasing the release anyway. Since the git hash is included in the version it should make it even easier to exactly know which version is being used.
[1]: https://www.kernel.org/pub/software/scm/git/docs/git-describe.html