On Wed 2026-01-14 11:42:58, Gerald Pfeifer wrote: > On Tue, 13 Jan 2026, Filip Kastl wrote: > > Whoops, I didn't replace all occurences of "pr" with "PR". Here is a fix. > > First of all thanks for the review, Alexander! > > > + <li><code>comment N</code> gets turned into a link to the > > <code>N</code>-th > > + comment under <i>this</i> bug.</li> > > <emph>this</emph> (since <i> is phyiscal, not logical markup). > > > + <li>Combining the two variants is also possible: > > + <code>rN-M-gXXXXXXX</code> will link to > > + <code>https://gcc.gnu.org/cgit/gcc/commit/?id=XXXXXXX</code>. So the > > + <code>gXXXXXXX</code> takes precedence. Note: You can use the script > > + <code>contrib/git-descr.sh</code> from the GCC's source tree to convert > > + commit hashes to this format.</li> > > Do we need to document this last variant given it ignores some of its > parameters? > > Or does contrib/git-descr.sh just create this format, hence we need to > document this? (That script's documentation is a bit, um, minimal.) > > > The patch is fine. Thank you, Filip! > > (I have some minor suggestions, yet do not want to derail your submission, > so may follow-up with a patch later on.) > > Gerald
Alright, I take this as an approval. I pushed the v3 patch with <i> changed to <em> (I expect you meant <em>). I list the last commmit variant because that's the variant I see (and use myself) most often. Indeed, this is the default (and perhaps the only?) output format of git-descr.sh. Thanks! Filip --- htdocs/bugs/management.html | 45 +++++++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) diff --git a/htdocs/bugs/management.html b/htdocs/bugs/management.html index b2bb740e..672f28bd 100644 --- a/htdocs/bugs/management.html +++ b/htdocs/bugs/management.html @@ -249,5 +249,50 @@ encounter a PR that is marked as "resolved fixed", but should be marked as a duplicate, please change the resolution. (You have to reopen the PR before you can resolve it as a duplicate.)</p> +<h2>Bugzilla Tips and Tricks</h2> + +<h3>Automatic Linking</h3> + +<p>When writing a description of a new bug or commenting on an already existing +bug, you can make use of certain shortcuts to link to other bugs, commits, +comments and similar stuff. Here is a (most likely incomplete) list of these +shortcuts:</p> + +<h4>Bugs, Comments and Attachments</h4> +<ul> + <li>A string <code>PR N</code> or <code>bug N</code> where + <code>N</code> is a Bugzilla bug ID automatically gets turned into a + link to the appropriate bug page.</li> + <li><code>attachment N</code> will link to the attachment with ID + <code>N</code>.</li> + <li><code>comment N</code> gets turned into a link to the <code>N</code>-th + comment under <em>this</em> bug.</li> + <li>You can use <code>bug N, comment M</code> to link to a comment + under a different bug. Using <code>PR</code> doesn't work here.</li> +</ul> +These shortcut keywords are case-insensitive. Except for the +<code>PR</code> keyword, these are actually not specific to GCC Bugzilla. +See <a +href=https://bugzilla.readthedocs.io/en/latest/using/tips.html#autolinkification> +Bugzilla documentation</a>. + +<h4>Commits</h4> +<ul> + <li><code>g:XXXXXXX</code> where <code>XXXXXXX</code> is a prefix of the + hash of a commit links to + <code>https://gcc.gnu.org/cgit/gcc/commit/?id=XXXXXXX</code>. The + prefix must be at least 7 characters long.</li> + <li><code>rN-M</code> links to + <code>https://gcc.gnu.org/cgi-bin/gcc-gitref.cgi?r=rN-M</code>. So + this way you can link to the <code>M</code>-th commit of GCC version + <code>N</code>.</li> + <li>Combining the two variants is also possible: + <code>rN-M-gXXXXXXX</code> will link to + <code>https://gcc.gnu.org/cgit/gcc/commit/?id=XXXXXXX</code>. So the + <code>gXXXXXXX</code> takes precedence. Note: You can use the script + <code>contrib/git-descr.sh</code> from the GCC's source tree to convert + commit hashes to this format.</li> +</ul> + </body> </html> -- 2.51.0
