| Message ID | 1484429641-7313-1-git-send-email-mkroken@gmail.com |
|---|---|
| State | Accepted |
| Headers | show |
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software. There is a problem though in semantics. Assuming your suggestion is accepted, when you build the version on your tree with dirty commits, you will see a hash which is not corresponding to the tree you have, but the remote one. This won't make sense. Signed-off-by: Morteza Milani <mrtz.milani@gmail.com> On Sun, Jan 15, 2017 at 1:04 AM, Magnus Kroken <mkroken@gmail.com> wrote: > 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 <mkroken@gmail.com> > --- > The referenced commit message says: > The new output format will look like "r2400+2-882472e" for dirty trees or like > "r2402-882472e" for clean ones. > > Since the example hashes are the same, I take this to mean that this was the intended behavior. > > Intended or not, I would suggest this anyway. If someone provides a LEDE version number from a dirty tree, > e.g. r2961+8-abcdef01, you need access to a LEDE Git tree and ability to run getver.sh to look up which > commit r2961 corresponds to. The short hash (abcdef01) is from the dirty tree, and can be anything that person has committed. > Appending the upstream base commit hash is useful when people ask for help and you want to track down the > commit they're based on, and you may not have a running LEDE build environment available. Knowing that a tree > is dirty (+8) is useful as well, but the commit hash is only useful to people who have access to the dirty tree. > > scripts/getver.sh | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/scripts/getver.sh b/scripts/getver.sh > index ecf048f..4d594d3 100755 > --- a/scripts/getver.sh > +++ b/scripts/getver.sh > @@ -40,7 +40,12 @@ try_git() { > REV="${UPSTREAM_REV}+$((REV - UPSTREAM_REV))" > fi > > - REV="${REV:+r$REV-$(git log --format="%h" -1)}" > + if [ -n "$UPSTREAM_BASE" ]; then > + REV="${REV:+r$REV-$(git log -n 1 --format="%h" $UPSTREAM_BASE)}" > + else > + REV="${REV:+r$REV-$(git log --format="%h" -1)}" > + fi > + > ;; > esac > > -- > 2.1.4 > > > _______________________________________________ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev
diff --git a/scripts/getver.sh b/scripts/getver.sh index ecf048f..4d594d3 100755 --- a/scripts/getver.sh +++ b/scripts/getver.sh @@ -40,7 +40,12 @@ try_git() { REV="${UPSTREAM_REV}+$((REV - UPSTREAM_REV))" fi - REV="${REV:+r$REV-$(git log --format="%h" -1)}" + if [ -n "$UPSTREAM_BASE" ]; then + REV="${REV:+r$REV-$(git log -n 1 --format="%h" $UPSTREAM_BASE)}" + else + REV="${REV:+r$REV-$(git log --format="%h" -1)}" + fi + ;; esac
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 <mkroken@gmail.com> --- The referenced commit message says: The new output format will look like "r2400+2-882472e" for dirty trees or like "r2402-882472e" for clean ones. Since the example hashes are the same, I take this to mean that this was the intended behavior. Intended or not, I would suggest this anyway. If someone provides a LEDE version number from a dirty tree, e.g. r2961+8-abcdef01, you need access to a LEDE Git tree and ability to run getver.sh to look up which commit r2961 corresponds to. The short hash (abcdef01) is from the dirty tree, and can be anything that person has committed. Appending the upstream base commit hash is useful when people ask for help and you want to track down the commit they're based on, and you may not have a running LEDE build environment available. Knowing that a tree is dirty (+8) is useful as well, but the commit hash is only useful to people who have access to the dirty tree. scripts/getver.sh | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)