https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93185
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rearnsha at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Plus we need to decide what exactly will go into gcc-cvs mails and into
bugzilla (I think right now the body is the same for both).
For the monotonically increasing trunk and release branch commits, we could use
special tags (tag the trunk whenever we branch off a release branch with some
uniquely named tags that would include the upcoming gcc major version and then
git describe --all --match 'r[0-9]*' ... | sed ...
to convert a git commit into say a rNN-NNNN syntax that we could handle in
http://gcc.gnu.org/rNN-NNNN redirects too and mention in the git-cvs/bugzilla.
E.g. r10-1234 would be 1234th trunk commit in gcc 10 (i.e. since gcc 9 branched
off), r11-2 2nd trunk commit after gcc 10 branched off.
My primary reason for this is bisect seed, with monotonically increasing such
numbers it will still allow by hand bisection which is impossible with git
hashes, but e.g. for gcc -v it could be shorter too, and we could have git
aliases to convert in both directions (if it is possible to write it, my git-fu
is very limited).
