Group-level merge requests (Super Merge)
Problem to solve
Many teams need to make changes across multiple projects to ship a feature. Changing each component one by one is laborious and results in a sub-optimal code review workflow. Additionally, organizations that use centralized version control systems may have CI/build systems that treat
HEAD as always integratable and therefore need to change
HEAD of all related projects in a single related change.
Nearly all products are composed of multiple components that are spread across multiple projects/repositories. For example
gitlab-ce relies on
gitlab-shell, and changes to these components are often coordinated with changes to GitLab. Often these changes should be reviewed together as a single logical change because together they result in one functional change that impacts a user. Spreading the code review over multiple independent changes to multiple projects can make it harder to review the change in the context of it's ultimate purpose.
In addition to the code review use case, some teams treat
HEAD of the same named branch as always integratable. This is typically true of teams using centralized version control systems like Perforce and means that a change spanning multiple repositories can be merged as a single change. These tools also provide a global history so that every version of the product can easily be checkout and built. A collection of Git repositories do not have these properties because they are independent of each other.
We should provide a single interface for performing a code review for changes that span multiple repositories (projects).
- An engineer creates a feature branch on
new-feature, writes the first version and opens a merge request for feedback
- A code reviewer points out that part of the change should be migrated to
The engineer creates a feature branch on
new-feature, makes the proposed change, and pushes the new commit to
gitlab-ce/new-featureand pushes the new branch to
When pushing the change to
gitaly/new-featurethe engineer is alerted to the ability to add the branch to her existing merge request:
This branch looks related to merge request gitlab-ce!XXX (branch `new-feature`) You can convert this merge request into a group merge request and add `gitaly/new-feature` by clicking: LINK
The engineer clicks the link which opens an interface to move the project merge request to a group merge request. This closes the project merge request like moving an issue to a different location.
The code reviewer can then continue the code review on the group merge request. Discussion and diff comments will be copied to the new merge request.
The code reviewer can merge the group merge request knowing that it will succeed or fail as a unit because GitLab will lock the target branch for writes of all the impacted projects for the duration of the Git merge process.
History spanning multiple projects
A repository of using Git submodules can be used to track the compatible versions of each repository. Scripts and hooks can be used to automatically manage this. This should optional and not necessary for gaining the benefits of a single code review interface.
GitLab should provide APIs to:
- create and update group merge requests (incl closing and reopening, adding new projects to the group merge request)
- move project merge requests to group merge requests
Example: use a meta repository to integrate lots of projects and create a history across all branches
pre-receivehook can be used to automatically create corresponding branches and commits on the meta repository
- system hook can be used to automatically convert any project merge request to group merge requests and add the meta repository