View hidden Pull Request comments in Bitbucket Server

[#1]

We've been making changes to the way Bitbucket Server Pull Requests surface hidden comments so that all comments are always available. Comments will be easy to find in the diff view even if they are outdated or if they were made in a different scope of changes to the one you are looking at now.

We've implemented the Other Comments feature in Bitbucket Server and Data Center 7.4. Look for the button in the file diff header when reviewing a long running Pull Request.

This button will only appear when there are "other comments" to display, the comments will display in a modal like this.

Below is a little more information about the problem space and why this new functionality is so useful

Pull Request scope

Bitbucket Server provides a number of functions to make reviewing code easier. One of these is allowing users to slice up the set of changes being reviewed by commit. The changes selector on the diff tab allows the user to select

• A single commit; or

• All changes in this pull request

What is iterative review

There is a third way to slice up the set of changes, a feature called iterative review. This feature allows users to only review new changes pushed since they last reviewed. Bitbucket Server will automatically detect when you last reviewed and allow you to select “Changes since you last reviewed” from the changes selector.

This is a handy feature for reviewers who only want to review the new changes, perhaps after they requested these changes in an initial review. The changes selector also marks up which commits are included. This feature is only invoked when a user has previously reviewed the PR, by setting their review status to APPROVED or NEEDS WORK . Different reviewers for the same Pull Request may see a different number of commits for their iterative review.

• One problem with being able to view a Pull Request in these different ways is that comments and tasks made in a specific scope of changes are not visible on the diff unless a user is currently viewing the changes inside that specific scope.
• Comments made in the “all changes” scope will be “drifted” to their correct line positioning as new changes are added. For example a comment on line 10 might move to line 12 after 2 new imports are included at the top of the file. Moving this comment is called drifting.
• When a comment can’t be drifted, usually because the line has been removed in a commit then a comment’s status is set to be OUTDATED.

Changes and the available change scope lifecycle

Let’s have a look at the lifecycle of a Pull Request and the available scope of changes to users. The green circles will represent new commits being pushed to a Pull Request.

When a single commit has been pushed to a Pull Request then the only view is that single commit. All changes are available but will show the same changes as viewing that single commit.

After a second commit is pushed there is now three different ways to view the changes. A user could view either of the commits individually, or all changes. If a reviewer had submitted a review after the first commit then the iterative review selector would be available, selecting it would show the one new commit, this view would be identical to just selecting the f549f53394d commit directly.

After a third commit is pushed, a user can view each commit individually or all changes. For iterative review there is two different permutations of changes depending on when a specific reviewer last reviewed. If a user had last reviewed this Pull Request with only 76e138f89a6 then their iterative review would contain two commits, both f549f53394d and 58577d1aaf9. For a user who had last reviewed with f549f53394d included then their iterative review would just be the changes in 58577d1aaf9.

The permutations of possible change scopes starts to multiply as more commits are added. After four commits there is now three different permutations of iterative review depending on when a specific reviewer last reviewed.

What about that old iterative review? I’ve added it here to demonstrate how comments can be hidden within the Pull Request. A user who had reviewed at commit 76e138f89a6 then used iterative review to review at commit 58577d1aaf9 will have left comments which are now no longer visible on the diff, because the changes selector doesn’t allow a user to specifically review changes from f549f53394d to 58577d1aaf9.

• There is no way for a user to select a custom commit range from the changes selector, the only commit range viewable is what the 'iterative review' makes available.
• Comments on inaccessible commit ranges still appear on the Overview tab under Activity. Depending on the amount of activity on a Pull Request, finding these can be difficult. You can now find these comments inside the "Other Comments" feature!

No more lost feedback

One solution to this issue was to always add your comments to “all changes” or to specific commits so they were always accessible. Unfortunately this workaround meant that many were not harnessing the benefits of iterative review. This is not a problem anymore since the comments will always be easily accessible behind the "Other Comments" button.

The release notes for Bitbucket Server and Data Center 7.4 are available here

[martinda14]

I am finding this complicated. Could you give us buttons to reset the iterative review, and to resolve/unresolve comments manually?

In my "Other Comments" button, I have both outdated and unseen comments. How does the coder get a complete overview with all the comments all on one page?

[Marc E. Johnson]

How do you do something like this on bitbucket cloud?  I can only see outdated comments by clicking into a popup window, that won't hyperlink reliably, and won't print, etc.   I just want to see all comments, outdated or not, on a flattened non-popup page in rendered html.  Thanks.