Page MenuHomeFreeBSD

newvers: tweak uname to be more useful
ClosedPublic

Authored by imp on Jan 25 2021, 8:02 PM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Dec 25, 11:59 AM
Unknown Object (File)
Mon, Dec 23, 5:30 AM
Unknown Object (File)
Sat, Dec 21, 10:20 AM
Unknown Object (File)
Tue, Dec 10, 9:50 PM
Unknown Object (File)
Tue, Dec 10, 1:10 AM
Unknown Object (File)
Mon, Dec 9, 4:22 AM
Unknown Object (File)
Sun, Dec 1, 6:11 AM
Unknown Object (File)
Fri, Nov 29, 7:23 AM

Details

Summary

The current uname is branch-cXXXX-gHASH

Three changes to make uname more useful.

  1. Move from using git rev-list --count to git rev-lis --count --first-parent since that gives a better, incrementing number.
  2. Report this count as 'vXXXXX' rather than 'cXXXXX' because c is part of a hash and we've changed the sematnics of XXXXX
  3. Remove g to make HASH cut and pastable.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 36478
Build 33367: arc lint + arc unit

Event Timeline

imp requested review of this revision.Jan 25 2021, 8:02 PM
imp created this revision.

I'm largely indifferent to the first, but I love deleting the 'g' from the hash.

rgrimes added a subscriber: rgrimes.

Yes please

This revision is now accepted and ready to land.Jan 25 2021, 9:11 PM

Two people in email suggested they didn't like this, people here largely do. I'm going to move forward with a note...

To summarize the objections:

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?

I'm agnostic on v vs n. Personally, I'd rather it be branch(version)-hash, but that's a much bigger change to newvers.sh

Followed by

Seconded, sorry for discussing the color of bikeshed, but 'v' is also
not intuitive to me. Since it is still a counter, and we are removing
the 'g' in the second part, cXXXXX-HASH is still distinguishable with
the old cXXXXX-gHASH.
Or, maybe call it gXXXXX-HASH which stands for git commit count XXXXX,
with hash value HASH?

I think that 'n' or 'v' are both fine choices. # I'd like to avoid since we use that for build number. g I think is not so clear a connection than either 'v' or 'n'.

If this were commits since the branch point, I'd lean more towards 'v' instead of 'n' since it's the Xth version of the branch. However, it's a count back to the start of the project, so maybe 'n' is better. Doing a count back to the branch point would be tricky, but possible. However, it adds needless complexity, imho.

I've sent a followup to arch@ and will let things cook for another few hours at leasat.

This revision was automatically updated to reflect the committed changes.