2008-03-31 21:50:05 +02:00
|
|
|
#!/bin/sh
|
2013-09-04 11:36:31 +02:00
|
|
|
#
|
|
|
|
# This scripts adds local version information from the version
|
|
|
|
# control systems git, mercurial (hg) and subversion (svn).
|
|
|
|
#
|
|
|
|
# If something goes wrong, send a mail the kernel build mailinglist
|
|
|
|
# (see MAINTAINERS) and CC Nico Schottelius
|
|
|
|
# <nico-linuxsetlocalversion -at- schottelius.org>.
|
|
|
|
#
|
|
|
|
#
|
2008-03-31 21:50:05 +02:00
|
|
|
|
|
|
|
usage() {
|
|
|
|
echo "Usage: $0 [srctree]" >&2
|
|
|
|
exit 1
|
|
|
|
}
|
|
|
|
|
|
|
|
cd "${1:-.}" || usage
|
|
|
|
|
|
|
|
# Check for git and a git repo.
|
2009-02-03 17:24:13 +01:00
|
|
|
if head=`git rev-parse --verify --short HEAD 2>/dev/null`; then
|
2013-09-04 11:36:31 +02:00
|
|
|
|
Makefile: properly account for custom tags in BR2_VERSION_FULL
BR2_VERSION_FULL is currently defined as follows:
BR2_VERSION_FULL := $(BR2_VERSION)$(shell $(TOPDIR)/support/scripts/setlocalversion)
This BR2_VERSION_FULL value then gets used as the "VERSION" variable
in the /etc/os-release file.
The logic of "setlocalversion" is that if it is exactly on a tag, it
returns nothing.
If it is on a tag + a number of commits, then it returns only
-XYZ-gABC where XYZ is the number of commits since the last tag, and
ABC the git commit hash (these are extracted from git describe).
This output then gets concatenated to BR2_VERSION which gives
something like 2020.05 or 2020.05-00123-g5bc6a.
The issue is that when you're on a tag specific to your project, which
is not a Buildroot YYYY.MM tag, then the output of setlocalversion is
empty, and all you get as VERSION in os-release is $(BR2_VERSION)
which is not really nice. Worse, if you have another non-official
Buildroot tag between the last official Buildroot tag/version and
where you are, you will get $(BR2_VERSION)-XYZ-gABC, but XYZ will not
correspond to the number of commits since BR2_VERSION, but since the
last tag that "git describe" as found, which is clearly incorrect.
Here is an example: you're on master, "make print-version" (which
displays BR2_VERSION_FULL) will show:
$ make print-version
2020.08-git-00758-gc351877a6e
So far so good. Now, you create a tag say 5 commits "before" master,
and show BR2_VERSION_FULL again:
$ git tag -a -m "dummy tag" dummy-tag HEAD~5
$ make print-version
2020.08-git-00005-gc351877a6e
This makes you believe you are 5 commits above 2020.08, which is
absolutely wrong.
So this commit simplifies the logic of setlocalversion to simply
return what "git describe" provides, and not prepend $(BR2_VERSION) in
the main Makefile. Since official Buildroot tags match official
Buildroot version names, you get the same output when you're on an
official Buildroot tag, or some commits above a Buildroot tag. An in
other cases, you get a sensible output. The logic is also adjusted for
the Mercurial case.
In the above situation, with this commit applied, we get:
$ make print-version
dummy-tag-6-g6258cdddeb
(6 commits instead of 5 as we have this very commit applied, but at
least it's 6 commits on top of the dummy-tag)
Finally, if you're not using a version control system, setlocalversion
was already returning nothing, so in this case, the Makefile simply
sets BR2_VERSION_FULL to BR2_VERSION to preserve this behavior.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2020-07-20 13:59:57 +02:00
|
|
|
atag="`git describe 2>/dev/null`"
|
|
|
|
|
|
|
|
# Show -g<commit> if we have no tag, or just the tag
|
|
|
|
# otherwise.
|
|
|
|
if [ -z "${atag}" ] ; then
|
|
|
|
printf "%s%s" -g ${head}
|
|
|
|
else
|
|
|
|
printf ${atag}
|
2008-04-01 11:53:14 +02:00
|
|
|
fi
|
|
|
|
|
|
|
|
# Is this git on svn?
|
|
|
|
if git config --get svn-remote.svn.url >/dev/null; then
|
2009-03-26 21:47:38 +01:00
|
|
|
printf -- '-svn%s' "`git svn find-rev $head`"
|
2008-03-31 21:50:05 +02:00
|
|
|
fi
|
|
|
|
|
2013-09-04 11:36:31 +02:00
|
|
|
# Update index only on r/w media
|
|
|
|
[ -w . ] && git update-index --refresh --unmerged > /dev/null
|
|
|
|
|
|
|
|
# Check for uncommitted changes
|
2008-03-31 21:50:05 +02:00
|
|
|
if git diff-index --name-only HEAD | grep -v "^scripts/package" \
|
|
|
|
| read dummy; then
|
|
|
|
printf '%s' -dirty
|
|
|
|
fi
|
|
|
|
|
|
|
|
# All done with git
|
|
|
|
exit
|
|
|
|
fi
|
|
|
|
|
|
|
|
# Check for mercurial and a mercurial repo.
|
support/scripts/setlocalversion: fix/improve Mercurial output
Commit 9e4ffdc8cfdf4c73f4fa8c66259a5aadaee4ae88 modified the output of
'setlocalversion' so that the Buildroot version tag is included in the
output, the version part was added in Makefile.
Due to differences in behavior of the used git and Mercurial commands, this
caused different output for the Mercurial case, in BR2_VERSION_FULL and thus
/etc/os-release and 'make print-version'. Assuming the official Buildroot
releases are tagged and no project-specific tags are present, the output
after commit 9e4ffdc8cfdf4c73f4fa8c66259a5aadaee4ae88 is:
-hg<commit>
whereas it is expected to be something like:
2020.02.6-hg<commit>
Change the Mercurial case in setlocalversion to behave similar to git,
looking up the latest tag if the current revision is not itself tagged.
The number of commits after the latest tag is not added, unlike in git, as
this value is not commonly present in Mercurial output, and its added value
can be disputed in this context. Even one commit could bring a huge change
to the sources, so in order to interpret the number one has to look at the
repository anyhow, in which case the commit ID can just be used.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2020-09-30 10:18:23 +02:00
|
|
|
# In the git case, 'git describe' will show the latest tag, and unless we are
|
|
|
|
# exactly on that tag, the number of commits since then, and last commit id.
|
|
|
|
# Mimic something similar in the Mercurial case.
|
support/scripts/setlocalversion: ignore user settings for Mercurial
setlocalversion will use 'hg id' to determine whether or not the current
revision is tagged. If there is no tag, the Mercurial revision is printed,
otherwise nothing is printed.
The problem is that the user may have custom configuration settings (in
their ~/.hgrc file or similar) that changes the output of 'hg id' in a way
that the script does not expect. In such cases, the Mercurial revision may
not be printed or printed incorrectly.
It is good practice to ignore the user environment when calling Mercurial
commands from a well-defined script, by setting the environment variable
HGRCPATH to the empty string. See also 'hg help environment'.
In the particular case of Nokia, a custom extension adds dynamic tags in the
repository, i.e. tags that are stored in a file external to the repository
and only visible when the extension is active. These tags should not
influence the behavior of setlocalversion as they are not official Buildroot
tags, i.e. even if a revision is tagged, the Mercurial revision should still
be printed.
Note that this still does not solve the problem where an organization adds
_real_ tags in their Buildroot repository. For example, there might be a
moving tag 'last-validated' or tags indicating in which product release that
Buildroot revision was used. In these cases, setlocalversion will still not
behave as expected, i.e. show the Mercurial revision.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-01-30 21:15:08 +01:00
|
|
|
if hgid=`HGRCPATH= hg id --id --tags 2>/dev/null`; then
|
setlocalversion: fix detection of hg revision for untagged versions
By default, cut prints the entire line if the specified delimiter is not
present at all:
$ printf "foo bar" | cut -d' ' -f2
bar
$ printf "foobar" | cut -d' ' -f2
foobar
In setlocalversion, cut is presented with the output of 'hg id' which has
the format:
"<revision> <tags-if-any>"
If the current revision is not tagged, the output of 'hg id' does not
contain the delimiter (space), cut prints the entire string, and
setlocalversion thinks the version is the tag.
As setlocalversion does not print anything for tagged versions, there is no
output overall, and no correct indication of the mercurial revision.
Fix by passing the extra cut option '--only-delimited', which suppresses
output if no delimiter is found.
This problem likely went unnoticed for so long, because the tag 'tip' (i.e.
most recent revision of the branch) is treated specially: in this case the
mercurial revision _is_ printed, i.e. the situation is treated as
'untagged'.
The problem is only seen when you are _not_ at the most recent revision in
your branch.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2017-04-26 14:43:11 +02:00
|
|
|
tag=`printf '%s' "$hgid" | cut -d' ' -f2 --only-delimited`
|
2008-03-31 21:50:05 +02:00
|
|
|
|
|
|
|
# Do we have an untagged version?
|
|
|
|
if [ -z "$tag" -o "$tag" = tip ]; then
|
support/scripts/setlocalversion: fix/improve Mercurial output
Commit 9e4ffdc8cfdf4c73f4fa8c66259a5aadaee4ae88 modified the output of
'setlocalversion' so that the Buildroot version tag is included in the
output, the version part was added in Makefile.
Due to differences in behavior of the used git and Mercurial commands, this
caused different output for the Mercurial case, in BR2_VERSION_FULL and thus
/etc/os-release and 'make print-version'. Assuming the official Buildroot
releases are tagged and no project-specific tags are present, the output
after commit 9e4ffdc8cfdf4c73f4fa8c66259a5aadaee4ae88 is:
-hg<commit>
whereas it is expected to be something like:
2020.02.6-hg<commit>
Change the Mercurial case in setlocalversion to behave similar to git,
looking up the latest tag if the current revision is not itself tagged.
The number of commits after the latest tag is not added, unlike in git, as
this value is not commonly present in Mercurial output, and its added value
can be disputed in this context. Even one commit could bring a huge change
to the sources, so in order to interpret the number one has to look at the
repository anyhow, in which case the commit ID can just be used.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2020-09-30 10:18:23 +02:00
|
|
|
# current revision is not tagged, determine latest tag
|
|
|
|
latesttag=`HGRCPATH= hg log -r. -T '{latesttag}' 2>/dev/null`
|
|
|
|
# In case there is more than one tag on the latest tagged commit,
|
|
|
|
# 'latesttag' will separate them by colon (:). We'll retain this.
|
|
|
|
# In case there is no tag at all, 'null' will be returned.
|
|
|
|
if [ "$latesttag" = "null" ]; then
|
|
|
|
latesttag=''
|
|
|
|
fi
|
|
|
|
|
|
|
|
# add the commit id
|
2008-03-31 21:50:05 +02:00
|
|
|
id=`printf '%s' "$hgid" | sed 's/[+ ].*//'`
|
support/scripts/setlocalversion: fix/improve Mercurial output
Commit 9e4ffdc8cfdf4c73f4fa8c66259a5aadaee4ae88 modified the output of
'setlocalversion' so that the Buildroot version tag is included in the
output, the version part was added in Makefile.
Due to differences in behavior of the used git and Mercurial commands, this
caused different output for the Mercurial case, in BR2_VERSION_FULL and thus
/etc/os-release and 'make print-version'. Assuming the official Buildroot
releases are tagged and no project-specific tags are present, the output
after commit 9e4ffdc8cfdf4c73f4fa8c66259a5aadaee4ae88 is:
-hg<commit>
whereas it is expected to be something like:
2020.02.6-hg<commit>
Change the Mercurial case in setlocalversion to behave similar to git,
looking up the latest tag if the current revision is not itself tagged.
The number of commits after the latest tag is not added, unlike in git, as
this value is not commonly present in Mercurial output, and its added value
can be disputed in this context. Even one commit could bring a huge change
to the sources, so in order to interpret the number one has to look at the
repository anyhow, in which case the commit ID can just be used.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2020-09-30 10:18:23 +02:00
|
|
|
printf '%s%s%s' "${latesttag}" -hg "$id"
|
Makefile: properly account for custom tags in BR2_VERSION_FULL
BR2_VERSION_FULL is currently defined as follows:
BR2_VERSION_FULL := $(BR2_VERSION)$(shell $(TOPDIR)/support/scripts/setlocalversion)
This BR2_VERSION_FULL value then gets used as the "VERSION" variable
in the /etc/os-release file.
The logic of "setlocalversion" is that if it is exactly on a tag, it
returns nothing.
If it is on a tag + a number of commits, then it returns only
-XYZ-gABC where XYZ is the number of commits since the last tag, and
ABC the git commit hash (these are extracted from git describe).
This output then gets concatenated to BR2_VERSION which gives
something like 2020.05 or 2020.05-00123-g5bc6a.
The issue is that when you're on a tag specific to your project, which
is not a Buildroot YYYY.MM tag, then the output of setlocalversion is
empty, and all you get as VERSION in os-release is $(BR2_VERSION)
which is not really nice. Worse, if you have another non-official
Buildroot tag between the last official Buildroot tag/version and
where you are, you will get $(BR2_VERSION)-XYZ-gABC, but XYZ will not
correspond to the number of commits since BR2_VERSION, but since the
last tag that "git describe" as found, which is clearly incorrect.
Here is an example: you're on master, "make print-version" (which
displays BR2_VERSION_FULL) will show:
$ make print-version
2020.08-git-00758-gc351877a6e
So far so good. Now, you create a tag say 5 commits "before" master,
and show BR2_VERSION_FULL again:
$ git tag -a -m "dummy tag" dummy-tag HEAD~5
$ make print-version
2020.08-git-00005-gc351877a6e
This makes you believe you are 5 commits above 2020.08, which is
absolutely wrong.
So this commit simplifies the logic of setlocalversion to simply
return what "git describe" provides, and not prepend $(BR2_VERSION) in
the main Makefile. Since official Buildroot tags match official
Buildroot version names, you get the same output when you're on an
official Buildroot tag, or some commits above a Buildroot tag. An in
other cases, you get a sensible output. The logic is also adjusted for
the Mercurial case.
In the above situation, with this commit applied, we get:
$ make print-version
dummy-tag-6-g6258cdddeb
(6 commits instead of 5 as we have this very commit applied, but at
least it's 6 commits on top of the dummy-tag)
Finally, if you're not using a version control system, setlocalversion
was already returning nothing, so in this case, the Makefile simply
sets BR2_VERSION_FULL to BR2_VERSION to preserve this behavior.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2020-07-20 13:59:57 +02:00
|
|
|
else
|
support/scripts/setlocalversion: fix/improve Mercurial output
Commit 9e4ffdc8cfdf4c73f4fa8c66259a5aadaee4ae88 modified the output of
'setlocalversion' so that the Buildroot version tag is included in the
output, the version part was added in Makefile.
Due to differences in behavior of the used git and Mercurial commands, this
caused different output for the Mercurial case, in BR2_VERSION_FULL and thus
/etc/os-release and 'make print-version'. Assuming the official Buildroot
releases are tagged and no project-specific tags are present, the output
after commit 9e4ffdc8cfdf4c73f4fa8c66259a5aadaee4ae88 is:
-hg<commit>
whereas it is expected to be something like:
2020.02.6-hg<commit>
Change the Mercurial case in setlocalversion to behave similar to git,
looking up the latest tag if the current revision is not itself tagged.
The number of commits after the latest tag is not added, unlike in git, as
this value is not commonly present in Mercurial output, and its added value
can be disputed in this context. Even one commit could bring a huge change
to the sources, so in order to interpret the number one has to look at the
repository anyhow, in which case the commit ID can just be used.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2020-09-30 10:18:23 +02:00
|
|
|
# current revision is tagged, just print the tag
|
Makefile: properly account for custom tags in BR2_VERSION_FULL
BR2_VERSION_FULL is currently defined as follows:
BR2_VERSION_FULL := $(BR2_VERSION)$(shell $(TOPDIR)/support/scripts/setlocalversion)
This BR2_VERSION_FULL value then gets used as the "VERSION" variable
in the /etc/os-release file.
The logic of "setlocalversion" is that if it is exactly on a tag, it
returns nothing.
If it is on a tag + a number of commits, then it returns only
-XYZ-gABC where XYZ is the number of commits since the last tag, and
ABC the git commit hash (these are extracted from git describe).
This output then gets concatenated to BR2_VERSION which gives
something like 2020.05 or 2020.05-00123-g5bc6a.
The issue is that when you're on a tag specific to your project, which
is not a Buildroot YYYY.MM tag, then the output of setlocalversion is
empty, and all you get as VERSION in os-release is $(BR2_VERSION)
which is not really nice. Worse, if you have another non-official
Buildroot tag between the last official Buildroot tag/version and
where you are, you will get $(BR2_VERSION)-XYZ-gABC, but XYZ will not
correspond to the number of commits since BR2_VERSION, but since the
last tag that "git describe" as found, which is clearly incorrect.
Here is an example: you're on master, "make print-version" (which
displays BR2_VERSION_FULL) will show:
$ make print-version
2020.08-git-00758-gc351877a6e
So far so good. Now, you create a tag say 5 commits "before" master,
and show BR2_VERSION_FULL again:
$ git tag -a -m "dummy tag" dummy-tag HEAD~5
$ make print-version
2020.08-git-00005-gc351877a6e
This makes you believe you are 5 commits above 2020.08, which is
absolutely wrong.
So this commit simplifies the logic of setlocalversion to simply
return what "git describe" provides, and not prepend $(BR2_VERSION) in
the main Makefile. Since official Buildroot tags match official
Buildroot version names, you get the same output when you're on an
official Buildroot tag, or some commits above a Buildroot tag. An in
other cases, you get a sensible output. The logic is also adjusted for
the Mercurial case.
In the above situation, with this commit applied, we get:
$ make print-version
dummy-tag-6-g6258cdddeb
(6 commits instead of 5 as we have this very commit applied, but at
least it's 6 commits on top of the dummy-tag)
Finally, if you're not using a version control system, setlocalversion
was already returning nothing, so in this case, the Makefile simply
sets BR2_VERSION_FULL to BR2_VERSION to preserve this behavior.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2020-07-20 13:59:57 +02:00
|
|
|
printf ${tag}
|
2008-03-31 21:50:05 +02:00
|
|
|
fi
|
|
|
|
|
|
|
|
# Are there uncommitted changes?
|
|
|
|
# These are represented by + after the changeset id.
|
|
|
|
case "$hgid" in
|
|
|
|
*+|*+\ *) printf '%s' -dirty ;;
|
|
|
|
esac
|
|
|
|
|
|
|
|
# All done with mercurial
|
|
|
|
exit
|
|
|
|
fi
|
|
|
|
|
|
|
|
# Check for svn and a svn repo.
|
2012-01-16 13:54:57 +01:00
|
|
|
if rev=`LC_ALL=C svn info 2>/dev/null | grep '^Last Changed Rev'`; then
|
2008-03-31 21:50:05 +02:00
|
|
|
rev=`echo $rev | awk '{print $NF}'`
|
2013-09-04 11:36:31 +02:00
|
|
|
printf -- '-svn%s' "$rev"
|
2008-03-31 21:50:05 +02:00
|
|
|
|
|
|
|
# All done with svn
|
|
|
|
exit
|
|
|
|
fi
|