Re: how to properly define version number of a package using git+COMMITID in the version?
On 02/03/2018 05:08 AM, Andreas Tille wrote:
On Fri, Feb 02, 2018 at 09:29:55AM -0700, Sebastian Kuzminsky wrote:
Another option is to use "git describe", which can be made to give you:
Alternatively use the date of the last commit like here
https://anonscm.debian.org/cgit/debian-med/libsmithwaterman.git/tree/debian/get-orig-source
I recommend against using the date of the most recent commit as a
component of the version number.
Git commits have two dates, the "author date" and the "commit date". You
can see them with (for example) "git show --pretty=fuller". The "author
date" is when the commit was first created. The "commit date" is when
the commit was most recently rewritten, for example by "git commit
--amend", "git rebase", or "git cherry-pick".
The date shown by by default with 'git log' and by 'git show
--format="%at"' (as used by the linked get-orig-source script) is the
author date. So it's very possible for that to move backwards in time,
which is something you *don't* want for version numbers.
You can do this experiment in a throw-away git repo:
git init date-test
cd date-test
echo hello > README
git add README
git commit -m 'first commit'
git checkout -b feature-branch
echo hello > FEATURE
git add FEATURE
git commit -m 'commit on the feature branch'
git checkout master
echo hello again >> README
git add README
git commit -m 'another commit on master'
date -d @$(git show --format="%at" | head -n1) +%Y-%m-%d-%T
2018-02-03-09:55:02
Now cherry-pick the commit from the feature branch and try again:
git cherry-pick feature-branch
date -d @$(git show --format="%at" | head -n1) +%Y-%m-%d-%T
2018-02-03-09:54:22
Notice how the date moved backwards after adding the feature branch to
master. A similar thing would have happened if the feature branch had
been rebased onto the tip of master and then fast-forward merged.
(Note that I added %T to the date format string since both commits were
made the same day, so they look indistinguishable with the original date
string.)
It's better to use 'git describe', which exists for exactly the purpose
of making monotonically increasing version numbers from git repos.
Here's how we do it in one of the projects I hack on:
https://github.com/LinuxCNC/linuxcnc/blob/master/scripts/get-version-from-git
https://github.com/LinuxCNC/linuxcnc/blob/master/scripts/githelper.sh
Our release branches have names like "X.Y", and our release tags have
names like "vX.Y.Z". The script figures out what release branch we're
on, which gives us the release tag glob to use. Then we pass that glob
to 'git describe --match' to get the version number.
--
Sebastian Kuzminsky
--
Sebastian Kuzminsky
Reply to: