<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> ### Problem to solve Code review should not be limited to only changed lines in changed files, because the context of those change lines is important. The context includes unchanged lines in unchanged files, and previous commits that have already merged that the change is built on. A reviewer should be able to bring these changes into attention of other reviewers and the author of the merge request. The most valuable code reviews are performed by people who are attentive to the broader context and impact of changes, and the reviewers who perform these high quality reviews should be supported with tools that reduce the barrier to leaving these kinds of reviews. ### Further details In addition to facilitating higher quality code review pre-merge, the primary code review workflow, the proposed capabilities provide primitives that enable secondary post-merge code review workflows. - **pre-merge** I want to be able to reference and discuss, or at the very least view, a previously merged commit in the process of reviewing a merge request. As the size of merge requests decrease, and the velocity of development increases, the need for introducing more context into merge requests increases so that meaningful discussions can occur - **move unresolved pre-merge discussions to a an actionable post-merge code review** is the simplest post-merge code review process which begins with an empty merge request, populated with unresolved discussions, ready to be continued and resolved. This provides a more streamlined and actionable flow than forcing all the issues back into a giant issue with cross links - **post-merge** code review of a collection of changes merged over time, like many tiny merge requests that together deliver a large complex change. **This is not the direct focus of this epic, but should be enabled in a very basic sense by these changes** - see https://gitlab.com/groups/gitlab-org/-/epics/872 ### Proposal | **Mockup** add commit | **Mockup** search commits | **Mockup** switching commits/comparison | |---|---|---| |  |  |  | From an existing merge request, as a reviewer: - I can add open commits that have already merged in to the target branch in the changes tab and leave comments on them - I can switch between the different commits that I have opened - My colleagues can see that I have added opened additional commits in the changes tab, and switch between them, and add more or remove them ### Customers - Discussed this with Zolst from CERN in October 2018 - https://gitlab.my.salesforce.com/0016100000fDO7w ### Links / references - Phabricator does it with 2 separate features: https://secure.phabricator.com/book/phabricator/article/reviews_vs_audit/