newvers: append commit count to uname version string

[emaste]

Summary

In a git-only world this provides a facsimile of a monotonically increasing version number.

[emaste]

In a fork based on our svn2git mirror (i.e., based on https://github.com/freebsd/freebsd master branch) this will produce a version number like: r348309+937a4a817304-c260384(wipbsd.20190326)-dirty. We'd generate e.g. r348309=937a4a817304-c360384(test) in a git svn-based fork.

In a git-only world (without modifications in the tree) we'd get something like 156c41aa9bed-c260203(master).

[cem]

If there is a cheap way to do it, it might be nice to stop counting at the first (latest) SVN revision. That way git starts over with lower "revision" numbers once an actual switch is made. It's also a shorter walk through git's object graph.

E.g.

git_lastsvn=$($git_cmd log -1 --notes --grep 'svn path=.*; revision=[0-9]*' | awk '{ print $2; exit }')
git_cnt=$($git_cmd rev-list --count ${git_lastsvn}..HEAD)

Which shows something more like "c27" for me (matches the depth of my git patch stack not present in SVN). Unlike your numbers, these numbers will float until we actually turn off SVN, so there's a tradeoff there. Since I'm not the target audience for this feature, maybe someone who likes revision numbers should share their preferences.

Functionally, I don't see anything wrong with the change.

[emaste]

Note that Git can internally store a generation count (tree height) and if that's a suitable proxy for us that can be instantaneous to calculate, however within a given branch a given generation count does not necessarily identify a unique commit.

Since any way we choose to represent this today is non-canonical I'll go with this and we can reconsider later when we start producing prototype/test releases from git.