GIT: Monotonically increasing trunk and release branch ids

[Jakub Jelinek <jakub at redhat dot com>]

Hi!

As I said earlier, one thing I find useful in svn compared to git are
the monotonically increasing revision numbers that we at Red Hat e.g. use
in our gcc bisect seed but I find it useful even in bugzilla everyday use.

With the help of various folks on IRC, I have something that seems to work.

We would need to add some tags (I wouldn't bother with pre-GCC 5 era,
because that doesn't have single number version numbers in the branch
names), like:
for r in 10 9 8 7 6; do
  git tag branchpoints/gcc-$r `git rev-list $(git merge-base origin/master origin/releases/gcc-$(expr $r - 1))..origin/master | tail -1`
done
git tag branchpoints/gcc-5 `git rev-list $(git merge-base origin/master origin/releases/gcc-4.9)..origin/master | tail -1`
and aliases:
git config --local alias.descr \!"f() { git describe --all --match 'branchpoints/gcc-[0-9]*' \${1-master} | sed -n 's,^tags/branchpoints/gcc-\\([0-9]\\+\\)-\\([0-9]\\+\\)-g[0-9a-f]*\$,r\\1-\\2,p;s,^tags/branchpoints/gcc-\\([0-9]\\+\\)\$,r\\1-0,p'; }; f"
git config --local alias.undescr \!"f() { r=\$(echo \$1 | sed -n 's,^r\\([0-9]\\+\\)-[0-9]\\+\$,\\1,p'); n=\$(echo \$1 | sed -n 's,^r[0-9]\\+-\\([0-9]\\+\\)\$,\\1,p'); test -z \$r && echo Invalid id \$1 && exit 1; h=\$(git rev-parse --verify --quiet origin/releases/gcc-\$r); if test -z \$h; then h=\$(git rev-parse --verify --quiet origin/master); fi; p=\$(git describe --all --match 'branchpoints/gcc-'\$r \$h | sed -n 's,^tags/branchpoints/gcc-[0-9]\\+-\\([0-9]\\+\\)-g[0-9a-f]*\$,\\1,p;s,^tags/branchpoints/gcc-[0-9]\\+\$,0,p'); git rev-parse --verify \$h~\$(expr \$p - \$n); }; f"

Then e.g.
$ git descr origin/master
r10-5824
$ git undescr r10-5824
42950b74c9b103676f99dc9f1a27859e3f7be436
$ git rev-parse origin/master
42950b74c9b103676f99dc9f1a27859e3f7be436
$ git descr branchpoints/gcc-10
r10-0
$ git undescr r10-0
fb7c6bf5aba75edc0cd439e0f07af3757bbda973
$ git descr branchpoints/gcc-10~
r9-7160
$ git undescr r9-7160
a5bc16f3199c9aa43aec5af2c2839a1cd4bfce1e
$ git rev-parse branchpoints/gcc-10
fb7c6bf5aba75edc0cd439e0f07af3757bbda973
$ git rev-parse branchpoints/gcc-10~
a5bc16f3199c9aa43aec5af2c2839a1cd4bfce1e
$ git descr2 origin/releases/gcc-9
r9-8116
$ git undescr r9-8116
3de43a2189f1e74b73b024109b922d7279dc7658

I'm sorry for my limited git-fu, could those branchpoints
tags be something that is fetched by default (given they would be added only
once a year for each trunk commit after the branching, usually the
BASE-VER bumping to N+1.0.0)?

As it is short, could it be something we'd put as first thing in the gcc-cvs
mail subjects (of course, only for trunk and release branch commits; like
the current svn mails start with rNNNNNN - ), and somewhere before or after the hash
in the body which also makes it into bugzilla?

Another thing, we right now have the useful https://gcc.gnu.org/rNNNNNN redirects.
For those (i.e. SVN revisions), do we want them to point to the read-only SVN repo
svnweb, or remap those to the gitweb?
Can we get similarly https://gcc.gnu.org/rNN-NNNN (for 1-2 decimal digits before - and 1-6
decimal digits after it) pointing to the gitweb using the git undescr and let
bugzilla turn those rNN-NNNN strings in the comments into URLs?

Yet another thing are git hashes.  For those, I'd be afraid that turning [0-9a-f]{7,}
into URLs might trigger too often, do we want to use some prefix, like g12345ab to
be https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=12345ab ?  If we'd add an prefix,
then we should also adjust the gcc-cvs mail content to use those prefixes in there.

Thoughts on this?

	Jakub