staging/pepe2k/scripts/getver.sh, branch v21.02.1

scripts: getver.sh: fix version based on stable branch

2021-02-21T17:42:38Z

When building from a local branch based off the "openwrt-21.02" branch, version computation is wrong, because the number of local commits is computed against master. As a result, it wrongly counts *all* commits since the beginning of the openwrt-21.02 branch as local commits. The fix is to compare to the openwrt-21.02 branch instead, which gives the expected result. A similar change had been applied to the openwrt-19.07 branch: 891022918d55 ("scripts: getver.sh: fix version based on stable branch") Signed-off-by: Baptiste Jonglez

scripts/getver.sh: silence rev-list errors

2020-11-02T07:39:49Z

Shallow copies are quite common on CI platforms nowadays, making REBOOT tag unavailable, thus producing following confusing errors in the build logs: fatal: Invalid revision range ee53a240ac902dc83209008a2671e7fdcf55957a..HEAD fatal: Invalid revision range ee53a240ac902dc83209008a2671e7fdcf55957a..0493d57e04774d47921a7d2014b567455d5dc16b Signed-off-by: Petr Štetiar

scripts/getver.sh: append short git hash based on upstream commit

2017-02-01T16:48:45Z

The short git hash suffix printed by getver.sh is taken from the latest local commit, change this to use the hash from latest upstream commit if available. This is considered the intended behavior based on commit message a642a11faca87e2a7bddc1fadb54253e2fc26e84, introducing getver.sh. Signed-off-by: Magnus Kroken Signed-off-by: Felix Fietkau

scripts: getver.sh: append Git short hash to revision

2016-12-02T15:38:55Z

Change getver.sh to append a short Git commit hash to the end of the artifical revision number. This way we still have order- and comparable commit numbers but also a direct relation to the Git commit. The new output format will look like "r2400+2-882472e" for dirty trees or like "r2402-882472e" for clean ones. Signed-off-by: Jo-Philipp Wich

scripts/getver.sh: treat all commits as local if can't find upstream

2016-11-21T13:36:04Z

If something goes wrong and script can't find upstream revision it will return something like: r2220 which looks like a valid upstream revision 2220. We cant' distinguish it from e.g. 2200 upstream commits and 20 local ones. The new format still provides revision number but also points clearly that is may be not the upstream one: r0+2220 Signed-off-by: Rafał Miłecki Acked-by: John Crispin < john@phrozen.org>

scripts/getver.sh: fix older git versions from printing stuff to stdout

2016-07-16T18:50:56Z

Older git versions seem output the original argument to stdout if there is no upstream, presumably because they try to do things with it internally. This can be prevented by passing --verify to it, which should be safe on newer git versions. Signed-off-by: Jonas Gorski

scripts/getver.sh: stop relying on the reboot tag

2016-07-14T11:37:58Z

It may not be present when cloning a staging tree or another fork Signed-off-by: Felix Fietkau

scripts/getver.sh: fix one more wc -l call

2016-07-13T14:56:41Z

The revision to hash conversion was missed when fixing up the script. Signed-off-by: Jonas Gorski

scripts/getver.sh: try to get branch/upstream automatically

2016-07-13T14:55:32Z

Instead of assuming master is the current branch and origin the right upstream, try to get both dynamically. If the current branch is not tracking any upstream, use the origin of the master branch. Signed-off-by: Jonas Gorski

scripts/getver.sh: fix revision number on BSD/MacOS

2016-07-09T18:02:21Z

Strip leading whitespace from wc -l output Signed-off-by: Felix Fietkau