newvers: tweak uname to be more useful

[imp]

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.

[emaste]

I like it

[kp]

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

[rgrimes]

Yes please

[imp]

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

[imp]

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.