View and add comments on previous commits in file view

Resources

PM @victorwu | UX @tauriedavis

Problem

As part of our high-level discussion product focus (https://gitlab.com/gitlab-org/gitlab-ce/issues/24688), we want to allow users to review code and comment on it just by viewing a simple file (https://gitlab.com/gitlab-org/gitlab-ce/issues/19055).

Proposed solution

• View comments on previous commits of a file. This allows a user to see why certain lines are the way they are. This is very similar to the git blame use case. You are staring at a line of code. You don't really understand it. So you use git blame to see who was the last person that touched that line and the commit message to get some context.
• Create a new file view (or modify an existing one) similar to the git blame view.
• The view should probably contain git blame information (commit messages and commit authors), since that's helpful.
• Git blame shows you the latest change and it's associated commit for each line in the file. In addition to this, the view should show any comments associated with each line of those commits.
• There's a lot of complexity here / possibilities here. Should we show all possible comments of all previous commits? Or just the latest one? (Similar to git blame.) How should the UI behave? What specific use cases are we solving for?
• Many of the scenarios are already outlined here: https://gitlab.com/gitlab-org/gitlab-ce/issues/19055

Example

• An existing git blame view of a file
• One of the commits in that git blame view, with a comment attached to that file
• Somehow that comment should appear in our new view.

Design

Details in the design will be worked out when this feature is scheduled to be worked on by designers and developers. Review existing comments in the discussion below and some of the designs there before determining the final design and scope of this issue.

Out of scope

We should not only allow viewing comments (and not adding them) for this iteration. This will enable us to gauge customer feedback, and perhaps even consider how to re-invent or replace the git blame view longer term. Once we have a better grasp of the use cases, then let's introduce adding comments in this view.