https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93185
Frédéric Buclin <LpSolit at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #10 from Frédéric Buclin <LpSolit at gmail dot com> ---
(In reply to Jakub Jelinek from comment #9)
> This was just trying to document what clearly is already implemented, e.g.
> for
> PR tree-optimization/90838 bugzilla already creates URL to
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90838
> There is no need to change anything.
Fun, I forgot I implemented this part already. :)
> But, while r10-5824-g42950b74c9b could be mapped directly to
> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=42950b74c9b
> and the last one to
> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;
> h=42950b74c9b103676f99dc9f1a27859e3f7be436
> by bugzilla, the first one can't, as it needs to run a few shell commands to
> determine the hash, so I'd like to r10-5824 to point to e.g.
> https://gcc.gnu.org/cgi-bin/gcc-gitref.cgi?r=r10-5824
> and let the cgi script perform redirection.
OK, I patched Bugzilla to point to
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=\1 for the last two forms and to
gcc-gitref.cgi for the first form.
> In https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01015.html Jason was
> suggesting that g: could take not just the hashes, but other ways git can
> use to describe the commit, so e.g. some tag name, or commit_hash~1,
> commit_hash^^ etc.
> For the redirects, I have tentatively used g:[0-9a-zA-Z._{}~^-]+ , but maybe
> / and @ should be accepted there too.
I always considered / and @ as evil in such URLs, because / has historically
been used to change directories in some security vulnerabilities and @ could be
used in URLs like user:password@host:port (remember FTP?). So I generally
prefer to be too restrictive with such regexps. For now, I kept the regexp
unchanged to match [0-9a-f] (hexadecimal) only. Let me know if you really want
me to let this regexp be more persmissive.
> https://git-scm.com/docs/gitrevisions says also HEAD@{5 minutes ago} , but
> guess
> we do not want to allow spaces in there in bugzilla
Sure, else we will match pretty much everything in long comments as the
probability is high to match {...}. :)
All done. Closing!
