Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> writes: > On Wed, Sep 13, 2017 at 12:18:12PM -0700, Guenter Roeck wrote: >> On Wed, Sep 13, 2017 at 11:55:38AM -0700, Greg Kroah-Hartman wrote: >> > On Wed, Sep 13, 2017 at 09:36:55AM -0700, Mark Brown wrote: >> > > On Wed, Sep 13, 2017 at 08:22:13AM -0700, Guenter Roeck wrote: >> > > > On Wed, Sep 13, 2017 at 10:05:00AM -0500, Tom Gall wrote: >> > > >> > > > > 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). >> > > >> > > Rebasing shouldn't be an issue for tags (they're not branches), and >> > > changes would a disaster no matter what. >> > >> > Can you push --force a tag? I've never tried that, don't want to mess >> > up a kernel.org tree by trying it out :) >> >> Yes. I don't recall if it is a direct --force or if you would have to >> remove the original tag first (with git push <repo> :refs/tags/<tag>). > > Ah, but then if someone had pulled the old tag, they would have to > delete it locally before they can pull in the new one. That's the main > reason I'll not do this... > > Again, use the make command that we have just for this reason... AFAICT, the make command will not generate a unique value, so, as often happens, a release is almost ready but one more patch is added/removed/modified etc. 'git describe' is the only way to get a unique value, that's also human readable. Kevin