[Bug web/93185] Support git commits as a link in bugzilla entries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93185
Frédéric Buclin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|--- |FIXED
--- Comment #10 from Frédéric Buclin ---
(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!
[Bug web/93185] Support git commits as a link in bugzilla entries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93185
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #9 from Jakub Jelinek ---
(In reply to Frédéric Buclin from comment #8)
> (In reply to Jakub Jelinek from comment #7)
> > r([0-9]{1,6}) to http://gcc.gnu.org/viewcvs/gcc?view=revision=\1
> > (what we have already, should be https? and perhaps we'll switch to some
> > redirector instead, so maybe https://gcc.gnu.org/r\1 instead?)
>
> I have updated Bugzilla to point to https instead of http.
Thanks.
> Which URL do you
> prefer: the current link to viewcvs/gcc?view=revision=\1 or the
> link to the redirector https://gcc.gnu.org/r\1 ? The advantage of the link
> to viewcvs is that you have one less redirection.
I agree, so let's change it when we decide what to do with SVN revisions.
The viewcvs will work for now.
> > pr([0-9]{1,6}) etc. to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=\1 (also
> > implemented, similar PR [a-z-]+/([0-9]{1,6}) )
>
> What's the point of [a-z]+/ in front of the bug ID if this part is useless
> to identify the bug report? I haven't implemented that part till I
> understand what this part is used for.
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.
> > (r[0-9]{1,2}-[0-9]{1,6}) to https://gcc.gnu.org/\1 (redirector to be
> > implemented)
>
> Waiting for the redirector to be implemented. Could meanwhile someone paste
> a valid example here so that I can use it for testing?
In https://gcc.gnu.org/ml/gcc/2020-01/msg00160.html I have posted a tentative
patch for the redirects, but as I said there, the gcc-gitref.cgi is not
implemented yet, hope it can be done say on Monday.
The aim is that e.g. 42950b74c9b103676f99dc9f1a27859e3f7be436 hash (but in the
testing reposurgeon repository, can't have something final because the current
conversion hasn't been finished yet) can be also written as
r10-5824
r10-5824-g42950b74c9b
r10-5824-g42950b74c9b103676f99dc9f1a27859e3f7be436
and all of those would in the end redirect to the same
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=42950b74c9b103676f99dc9f1a27859e3f7be436
(note, as this hash is from test repo, it won't really work as is).
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.
r10-5824 stands for 5824's commit after the first one on trunk after branching
gcc 9, r10-0 stands for the first commit on trunk after branching gcc 9,
its parent commit is r9-7160 (in the test repo) and r9-7161 is the first gcc 9
branch commit after branching gcc 9.
> > g:([0-9a-zA-Z_-]+) to https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=\1
>
> Done, but I have restricted the regexp to ([0-9a-f]{7,40}) as the hash is in
> hexadecimal form, so we don't need (nor want) g-z A-Z _ and -.
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.
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 and after all, stuff like
g:master@{yesterday} is really meaningless in bugzilla comments.
But sure, accepting hashes is the most common need, thinking about it even
g:master isn't very useful because it is a moving target. CCing Jason on this.
Perhaps those make only sense for the redirects and not the bugzilla comments.
> > r[0-9]{1,2}-[0-9]{1,6}-g([0-9a-f]{7,40}) to
> > https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=\1
> > ?
>
> Could someone paste a valid example here so that I can test it too?
See above, that is the:
r10-5824-g42950b74c9b
r10-5824-g42950b74c9b103676f99dc9f1a27859e3f7be436
[Bug web/93185] Support git commits as a link in bugzilla entries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93185
Frédéric Buclin changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |LpSolit at gmail dot com
--- Comment #8 from Frédéric Buclin ---
(In reply to Jakub Jelinek from comment #7)
> r([0-9]{1,6}) to http://gcc.gnu.org/viewcvs/gcc?view=revision=\1
> (what we have already, should be https? and perhaps we'll switch to some
> redirector instead, so maybe https://gcc.gnu.org/r\1 instead?)
I have updated Bugzilla to point to https instead of http. Which URL do you
prefer: the current link to viewcvs/gcc?view=revision=\1 or the link
to the redirector https://gcc.gnu.org/r\1 ? The advantage of the link to
viewcvs is that you have one less redirection.
> pr([0-9]{1,6}) etc. to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=\1 (also
> implemented, similar PR [a-z-]+/([0-9]{1,6}) )
What's the point of [a-z]+/ in front of the bug ID if this part is useless to
identify the bug report? I haven't implemented that part till I understand what
this part is used for.
> (r[0-9]{1,2}-[0-9]{1,6}) to https://gcc.gnu.org/\1 (redirector to be
> implemented)
Waiting for the redirector to be implemented. Could meanwhile someone paste a
valid example here so that I can use it for testing?
> g:([0-9a-zA-Z_-]+) to https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=\1
Done, but I have restricted the regexp to ([0-9a-f]{7,40}) as the hash is in
hexadecimal form, so we don't need (nor want) g-z A-Z _ and -.
For testing purposes: g:d3cf980217ce13b1eda01d4c42a7e3afd2bf3217 g:d3cf9802
g:01invalid234hash567
> r[0-9]{1,2}-[0-9]{1,6}-g([0-9a-f]{7,40}) to
> https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=\1
> ?
Could someone paste a valid example here so that I can test it too?
[Bug web/93185] Support git commits as a link in bugzilla entries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93185
--- Comment #7 from Jakub Jelinek ---
So, could bugzilla change to handle (from
https://gcc.gnu.org/ml/gcc/2020-01/msg00147.html ) words with regexps:
r([0-9]{1,6}) to http://gcc.gnu.org/viewcvs/gcc?view=revision=\1
(what we have already, should be https? and perhaps we'll switch to some
redirector instead, so maybe https://gcc.gnu.org/r\1 instead?)
pr([0-9]{1,6}) etc. to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=\1 (also
implemented, similar PR [a-z-]+/([0-9]{1,6}) )
(r[0-9]{1,2}-[0-9]{1,6}) to https://gcc.gnu.org/\1 (redirector to be
implemented)
g:([0-9a-zA-Z_-]+) to https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=\1
r[0-9]{1,2}-[0-9]{1,6}-g([0-9a-f]{7,40}) to
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=\1
?
[Bug web/93185] Support git commits as a link in bugzilla entries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93185 --- Comment #6 from Martin Liška --- Created attachment 47613 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47613=edit Github git reference I like what Github does. You can paste a git hash in a text, it's later shortened and one can see nice hover on the hash.
[Bug web/93185] Support git commits as a link in bugzilla entries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93185 --- Comment #5 from joseph at codesourcery dot com --- On Wed, 8 Jan 2020, jakub at gcc dot gnu.org wrote: > I thought it is this Saturday/Sunday. Yes, I intend to do the conversion this weekend.
[Bug web/93185] Support git commits as a link in bugzilla entries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93185 --- Comment #4 from Jakub Jelinek --- I thought it is this Saturday/Sunday.
[Bug web/93185] Support git commits as a link in bugzilla entries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93185 --- Comment #3 from Martin Liška --- > When will the move to git take place? Roughly in 2 weeks.
[Bug web/93185] Support git commits as a link in bugzilla entries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93185 Frédéric Buclin changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-07 Ever confirmed|0 |1 --- Comment #2 from Frédéric Buclin --- (In reply to Martin Liška from comment #0) > Once we'll switch to git, it would be handy to refer in bugzilla to git > commits with their corresponding hashes. Similarly to currently existing > r123456. When will the move to git take place?
[Bug web/93185] Support git commits as a link in bugzilla entries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93185 Jakub Jelinek changed: What|Removed |Added CC||rearnsha at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- 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- syntax that we could handle in http://gcc.gnu.org/rNN- 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).
