From discussion on !1509, some points came up:
- How to avoid very large merge requests?
- What is our merge request workflow?
I argued that splitting merge requests does not add a lot of value. I provided the following arguments:
- A reviewer can choose to review only some of the patches in the merge requests. Many project that distribute patches on mailing lists do this and Gitlab has UI that allows this.
- The reviewer could cherry-pick some patches and leave comments on the rest.
- Actual effort for the reviewer is not reduced if merge request is split (it is reduced when patches are logically organized).
- Testing effort is increased when merge requests are split.
- When merge requests are split and they depend on one another, Gitlib anyway shows large changes for merge requests that depend on others. This gets complicated when there are multiple dependencies.