Change in the uname

[Ian Lepore]

On Mon, 2021-01-25 at 13:04 -0700, Warner Losh wrote:
> Now that we have some experience with git, I'd like to propose we
> tweak the
> uname a little.
> 
> Right now it is branch-cXXXXX-gHASH.
> 
> First problem: cXXXX isn't linear. It suffers the same issues that
> git log
> does in that it includes all changes from merge commits back to a
> common
> ancestor. However, branch~1234 (1234 commits before the tip of
> branch)
> doesn't count those.
> 
> Solution: change this to vXXXX and add --first-parent to the git rev-
> list
> command. This will give us something we can use with the
> branch~number
> notation to track down versions more easily and allow people moving
> forward
> 100 commits to see the v number increment by 100 commits. I'm
> changing c->v
> here for two reasons. (1) c is a valid hex character so cXXXXX looks
> like a
> hash and (2) we're changing the semantic meaning of XXXXX, so this
> will
> make things unambiguous. This will also make it easier to find the
> revision
> with the branch~123 notation should that ever become necessary (and
> the v
> number would decrement by 123 when people do this).
> 
> Granted, this isn't a super-huge deal since we have the hash, but it
> will
> make things a bit more predictable and eliminate at least one source
> of
> confusion.
> 
> Second problem: gHASH isn't cut-and-pastable. And it makes it look
> like a
> git describe token when it isn't.
> 
> Solution: delete the 'g'.
> 
> So the new uname will be branch-vXXXXX-HASH.
> 
> I'd like to push this to stable/13 as well before the release so
> we're not
> stuck with two versions.
> 
> See https://reviews.freebsd.org/D28338 for the proposed change.
> 
> Comments?
> 
> Warner

That all sounds good, except the 'v' is a bit odd, normally it implies
a "version" number, which isn't exactly what this is.  How about 'n' or
'#' since it's just a count?

-- Ian