On 13.01.26 12:48, Jakub Jelinek wrote: > On Tue, Jan 13, 2026 at 12:35:07PM +0100, Frank Scheiner wrote: >> On 13.01.26 12:27, Jonathan Wakely wrote: >>> On Tue, 13 Jan 2026 at 11:26, Jonathan Wakely <[email protected]> wrote: >>>> >>>> On Tue, 13 Jan 2026 at 11:10, Frank Scheiner wrote: >>>>> BTW, I have not yet found out how to derive a revision like the just >>>>> mentioned one from a git commit hash. I know that it includes a >>>>> shortened commit hash and I assume the major GCC version number at >>>>> the start, but how can I in general determine such a revision from a >>>>> full git commit hash? >>>> >>>> Using the gcc-descr and gcc-undescr aliases provided by the >>>> https://gcc.gnu.org/gitwrite.html#customization setup. >>> >>> Or the contrib/git-descr.sh and contrib/git-undescr.sh scripts, which >>> are what the aliases use. >>> >>> $ git help gcc-descr >>> 'gcc-descr' is aliased to '!f() { "`git rev-parse >>> --show-toplevel`/contrib/git-descr.sh" $@; } ; f' >>> $ git help gcc-undescr >>> 'gcc-undescr' is aliased to '!f() { "`git rev-parse >>> --show-toplevel`/contrib/git-undescr.sh" $@; } ; f' >> >> Thanks! > > Note, the hashes like r10-2142-gec8ac265ff21fb can be used directly > by git, git diff r10-2142-gec8ac265ff21fb^ r10-2142-gec8ac265ff21fb > etc. works just fine. In the even more shortened version, like > r10-2142, you need the git gcc-undescr command to transform it to > git hash. Or you can use https://gcc.gnu.org/r10-2142 > to see it with gitweb.
Nice! > And the reason why these exist is that normal git hashes give on the first > sight no information how old a commit is and which commit is newer than > another one. > With rNN-NNNN-gHHHHHHHH you know immediately on which upstream branch > the commit was committed (for trunk it is always the version of the upcoming > release) and the NNNN in there is number of commits since branchpoint, so > when we've branched off gcc 15 branch, there was r16-0 commit right after > branchpoint and so on, so you can easily know that r16-500 was roughly from > May 2025, while r16-6700 is very recent commit. Thanks for the detailed explanations. Thats's really useful. I'll definitely make use of this notation in the future. > The shorter form is meant especially for gcc bugzilla bug subjects so that > it is not too long, while the ones including hash are meant e.g. for > bugzilla comments. bugzilla links such strings to the gitweb URLs too. Yeah, the bugzilla is where I first saw this notation, but had no idea how that "magic" works (-:. That auto-linking will come in handy in future bug reports, now that I know how this can be accomplished. Cheers, Frank
