You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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
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
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.
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.
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