On Wed, Sep 13, 2017 at 10:05:00AM -0500, Tom Gall wrote: > On Tue, Sep 12, 2017 at 10:49 PM, Greg Kroah-Hartman > <gre...@linuxfoundation.org> wrote: > > On Tue, Sep 12, 2017 at 09:27:45PM -0500, Tom Gall wrote: > >> > >> > On Sep 12, 2017, at 11:58 AM, Greg Kroah-Hartman > >> > <gre...@linuxfoundation.org> wrote: > <snip> > >> > >> Results from testing on Linaro’s small but growing test farm. > >> > >> ------------------------------------------------------------------------ > >> Summary > >> ------------------------------------------------------------------------ > >> > >> kernel: 4.9.50-rc1 > >> kernel-repo: > >> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > >> kernel-branch: linux-4.9.y > >> kernel-commit: edfaa5f69b96ae777b0acd2bfe1da26e21592001 > >> kernel-describe: v4.9.49-15-gedfaa5f69b96 > > > > Howcome 'git describe' does not show 4.9.50-rc1? > > git describe looks for the most recent tag. > > Since there isn't a 4.9.50-rc1 tag, we get 4.9.49 + 15 patches etc. > > Does it make sense to create tags for the RC(s) so git describe gets > it right? Given the right version is in the Makefile kinda feels like > that'd be a belt and suspenders approach. > Depends. A tag only makes sense if the branch isn't rebased, otherwise (if the tag can change) it would be misleading (as would be to report the version number from Makefile).
I usually don't report the SHA, mostly for historic reasons from times when I had to create the git branch myself. I sometimes report it if/when I notice that the branch changed after the review request e-mail. Given that, I think reporting the SHA is better, since it reports clearly which version was tested. Guenter
