Simon Peyton Jones via ghc-devs
Ben, Matthew
I wrote up notes on how to get from MR to issue, and from issue to MR, in my help page: https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/git-lab-spj (See "Issues" and "Merge requests" headings)
One note unrelated to the MR-to-issue matter: * Regarding high zoom levels causing the interface to be truncated: you may want to switch to the "fluid" layout width option (see [1]). I quickly tried it and it seems to be a bit more tolerant of zooming than the default fixed-width layout. [1] https://gitlab.haskell.org/profile/preferences
Alas, it seems that I was lying
* Issue #16411 does not have a "relevant merge request" link to MR!520, even though the latter plainly mentions the former. That seems deeply strange, and makes it hard to see if the issue has a MR, let alone which one it is.
I believe the reason for this is that !520 was opened before #16411 was imported. This is an unfortunate consequence of the fact that GitLab only scans for references when a comment/MR/issue is created or edited, not when it is rendered. I triggered a rescan of the description of !520 (by making a simple whitespace edit) and the expected reference was created.
* Somehow MR!520 says "closes #16411" rather than just "mentions #16411". Perhaps this is good, but how did it know to do that?
It matches the commit messages and merge request description against a regular expression. The default regular expression essentially matches phrases like * Fixes #1234 * Fixed #1234 * Closes #1234 * Closed #1234 occurring anywhere in the message. Given that we generally want contributors to review tickets before closing them, I think this is far too liberal. However, earlier today I made this significantly more selective. The new regular expression only matches lines starting with "Closes #1234". This still allows the auto-closure feature to be used but should greatly reduce the chance that it is inadvertently triggered. Cheers, - Ben