Citeren Bjørn Mork <bj...@mork.no>:
Rafał Miłecki <zaj...@gmail.com> writes:
From: Rafał Miłecki <ra...@milecki.pl>
Counting commits to determine revision number is a wrong idea when there
are branches in a project. This could generate the same revision for
different git commits, e.g.:
For master branch:
./scripts/getver.sh bb9d2aa868
r3438-bb9d2aa868
For lede-17.01 branch:
./scripts/getver.sh 2e206c79cc
r3438-2e206c79cc
Yes, this choice has always puzzled me...
Let's use git's sha1 instead and add amount of local commits on top of
this, e.g.:
./scripts/getver.sh
c00fbaf670+3
Maybe a stupid question, but why not simply use "git describe"? That
way you'll get the nice short aliases for tagged releases with no extra
fuzz.
Some examples:
Branch based on v17.01.2 with 2 local commits:
bjorn@canardo:/usr/local/src/lede$ git describe
v17.01.2-2-g76b6bed119a1
Current 17.01 branch:
bjorn@canardo:/usr/local/src/lede$ git describe
v17.01.2-1-ga6b5ddfd9b87
The 17.01.0 release branch:
bjorn@canardo:/usr/local/src/lede$ git describe
v17.01.0
Current master branch:
bjorn@canardo:/usr/local/src/lede$ git describe
reboot-4409-g19ac87995421
Isn't this exactly what you want? Note the even though you can have
many branches with 4409 commits on top of the 'reboot' tag, there is
only one containing commit g19ac87995421. So this version scheme is
unique.
Whatever scheme is used, please use something which continuously
increments. I keep local builds for a while and it is very useful to
be able to see in a glance if one build is more recent than another one.
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
