What is the expected "use-case" of merge-request "Discussions" for code-review?

In my team, we recently switched to a merge-request based workflow. The aim is to reap the benefits from code-reviewing.

The way we work right now is as follows:

  • One person has a “master” project on GitLab.
  • Collaborators fork this and submit merge-requests.
  • The “master” reviews the code and attaches comments to lines using GitLab launching a discussion on that code-fragment.
  • If the discussion is resolved due to a code-change, a collaborator adds a comment to the discussion referencing the commit hash in which the code was applied.
  • The “master” reviews the commit in question and - if he’s happy with it - resolves the discussion.

The bullet-point in bold is unwieldy. The collaborator must manually get the hash and copy/paste it in the discussion.

We decided to do this to solve the following problems:

  • When looking at the “changes” tab you only see the “latest” snapshot.
  • When using the “Compare to Previous Version” button in the merge-request page and there are several pending discussions, it’s hard to tell which points were tackled in those new commits. As an example, a recent MR resulted in 12 separate discussions. The following push by a collaborator dealt with only 3 of those discussions. While manually matching the discussions with the latest commits is possible it’s unwieldy.

Having the commit-hash directly in the discussion allows the reviewer to immediately jump to the proposed changes.

We’ve looked to see if a commit-message or slash-command can somehow trigger a commit to be associated with a discussion, but could not find anything.

My question is: Is our workflow flawed? Are we missing something in GitLab that would make this workflow easier?