diff mbox

[LEDE-DEV] scripts: getver.sh: use sha1 as base and drop r* format

Message ID 20170615121756.8831-1-zajec5@gmail.com
State Changes Requested
Headers show

Commit Message

Rafał Miłecki June 15, 2017, 12:17 p.m. UTC
From: Rafał Miłecki <rafal@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

Let's use git's sha1 instead and add amount of local commits on top of
this, e.g.:
./scripts/getver.sh
c00fbaf670+3

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
 scripts/getver.sh | 14 ++++++--------
 1 file changed, 6 insertions(+), 8 deletions(-)

Comments

Felix Fietkau June 15, 2017, 12:20 p.m. UTC | #1
On 2017-06-15 14:17, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@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
> 
> Let's use git's sha1 instead and add amount of local commits on top of
> this, e.g.:
> ./scripts/getver.sh
> c00fbaf670+3
> 
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
NACK. If you care about correctness, I think we should have some branch
info in there instead. The numbers are still useful to get a rough
estimate of how old a particular build is.

- Felix
Bjørn Mork June 15, 2017, 12:33 p.m. UTC | #2
Rafał Miłecki <zajec5@gmail.com> writes:

> From: Rafał Miłecki <rafal@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.



Bjørn
Arjen de Korte June 15, 2017, 12:44 p.m. UTC | #3
Citeren Bjørn Mork <bjorn@mork.no>:

> Rafał Miłecki <zajec5@gmail.com> writes:
>
>> From: Rafał Miłecki <rafal@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.
diff mbox

Patch

diff --git a/scripts/getver.sh b/scripts/getver.sh
index 9175f411db..17b3dd64ae 100755
--- a/scripts/getver.sh
+++ b/scripts/getver.sh
@@ -27,20 +27,18 @@  try_git() {
 		BRANCH="$(git rev-parse --abbrev-ref HEAD)"
 		ORIGIN="$(git rev-parse --verify --symbolic-full-name ${BRANCH}@{u} 2>/dev/null)"
 		[ -n "$ORIGIN" ] || ORIGIN="$(git rev-parse --verify --symbolic-full-name master@{u} 2>/dev/null)"
-		REV="$(git rev-list ${REBOOT}..$GET_REV | wc -l | awk '{print $1}')"
 
 		if [ -n "$ORIGIN" ]; then
 			UPSTREAM_BASE="$(git merge-base $GET_REV $ORIGIN)"
-			UPSTREAM_REV="$(git rev-list ${REBOOT}..$UPSTREAM_BASE | wc -l | awk '{print $1}')"
+			UPSTREAM_BASE_ABBR="$(git log -n 1 --format="%h" $UPSTREAM_BASE)"
+			LOCAL_COMMITS="$(git rev-list ${UPSTREAM_BASE}..$GET_REV | wc -l | awk '{print $1}')"
 		else
-			UPSTREAM_REV=0
+			UPSTREAM_BASE_ABBR="unknown"
+			LOCAL_COMMITS="$(git rev-list $GET_REV | wc -l | awk '{print $1}')"
 		fi
+		[ $LOCAL_COMMITS -eq 0 ] && LOCAL_COMMITS=""
 
-		if [ "$REV" -gt "$UPSTREAM_REV" ]; then
-			REV="${UPSTREAM_REV}+$((REV - UPSTREAM_REV))"
-		fi
-
-		REV="${REV:+r$REV-$(git log -n 1 --format="%h" $UPSTREAM_BASE)}"
+		REV="$UPSTREAM_BASE_ABBR${LOCAL_COMMITS:++$LOCAL_COMMITS}"
 
 		;;
 	esac