Date: Mon, 25 Jan 2021 14:03:48 -0700 From: Ian Lepore <ian@freebsd.org> To: Warner Losh <imp@bsdimp.com>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: Change in the uname Message-ID: <10fec1da415cd8d3c080a2173b9245ff35fceac8.camel@freebsd.org> In-Reply-To: <CANCZdfqYhdgbPiMc41hSoBoPNVMwJbp%2Bks5Jxic-fAAN=d8Cqg@mail.gmail.com> References: <CANCZdfqYhdgbPiMc41hSoBoPNVMwJbp%2Bks5Jxic-fAAN=d8Cqg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?10fec1da415cd8d3c080a2173b9245ff35fceac8.camel>