With the case of asking an invalid version that is too big, getver.sh
might return an invalid output in the form of HEAD~-2260475641.
This is caused by BASE_REV - GET_REV using a negative number.
Prevent this by checking if BASE_REV - GET_REV actually return 0 or a
positive number and set REV variable accordingly. With the following
change, invalid revision number will result in unknown printed instead
of the invalid HEAD~-NUMBERS output.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
(cherry picked from commit 9e49e0a6c4)
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 <ynezz@true.cz>
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 a642a11fac,
introducing getver.sh.
Signed-off-by: Magnus Kroken <mkroken@gmail.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
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 <jo@mein.io>
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 <rafal@milecki.pl>
Acked-by: John Crispin < john@phrozen.org>
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 <jonas.gorski@gmail.com>
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 <jonas.gorski@gmail.com>
This is not a valid option in older git version, used in e.g. RHEL6.
Reported-by: Steven Haigh <netwiz@crc.id.au>
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
Change the revision output to r<upstream-revision>+<local commits> so
it is easier to get the base revision (and see if there are local
commits).
Example:
$ ./scripts/getver.sh
r794+3
$
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
Path to the Git repository directory can be overriden by using the '$GIT_DIR'
environment variable. This patch improves detection of Git repository by using
'git-rev-parse', which respects '$GIT_DIR' environment variable, instead of just
checking the existence of '.git' directory.
Signed-off-by: Vasilis Tsiligiannis <acinonyx@openwrt.gr>
SVN-Revision: 49165
Git internals are referenced by .git which isn't necessarily a
directory. It may also be a file that references the actual .git
directory using the gitdir directive.
If .git is assumed to be a directory the build will not be able to get
the correct version when openwrt is included as a git submodule because
when used as a submodule .git will actually be a file referencing to a
subdirectory in the parent's git dir.
When the correct version is not detected some image generation tools
will fail because the OpenWrt string will be 'OpenWrtunknown' which is
too long for some header formats.
Signed-off-by: Felix Kaechele <heffer@fedoraproject.org>
SVN-Revision: 44452
