There are many places to host a Git repository like GitLab.com, GitHub.com and of course self hosting too. Furthermore, Git is a distributed version control system, and GitLab should the support distributed workflows suported by Git. **Merging changes between projects regardless of where they are stored should be easy.** GitLab should make it possible to send and receive changes from other Git repositories, and should use the [Git patch format](https://git-scm.com/docs/git-format-patch) because it is the standard format for transferring changes in a distributed format. 1. **Scenario:** a bug is found in an external open source dependency (hosted on GitHub.com) that requires a non-trivial fix. A common process is to fork the upstream project privately (self-host GitLab), develop a fix, and publish a new private version of the dependency. This makes it fast to resolve the issue, and limits the risk of private work being exposed in code comments, commit messages, or discussion on the public upstream project. There should be a simple workflow for contributing fixes upstream that protects the organization, makes it easy to get back on to a public release, and support the projects that the organization is using. 1. **Scenario:** I prefer to work on GitLab.com or my own self hosted instance and contribute upstream occasionally. I want to be able to work on my patch on my fork (clone) in GitLab rather than a fork on GitHub but be able to contribute my patch with a single click. > Note: this proposal is for **distributed merge requests** in contrast to **federated merge requests** – support for one should not be the future exclusion of the other. ### Vision The GitLab is a single application with many benefits from integrated CI, issues, epics, monitoring and more. The lack of simple interoperability between Git servers to share code creates islands/walls that limit collaboration. Git is distributed makes it easy to move code from server to server, but a code review is the generally accepted practice before accepting code from one repository/server to another. Within a single server merge requests are used, but there isn't an easy way to do a code review of a server to server merge. **What does a might a distributed merge request look like in practice?** Instead of specifying a target branch on the local GitLab repository, specify a target branch/repo on a different server by providing the URL to the Git repo (we'll need some sort of detection system to work out what's at the other end). The merge request will only live on the source GitLab instance until the merge request is published. Publishing would require equivalent permissions to merging to make sure that a private organization can do the quality/review process they need to be able to share the work publicly. ### Proposal #### Support for patches 1. Create and update merge request via email MVC https://gitlab.com/gitlab-org/gitlab-ce/issues/40830 Requires write permissions to create a feature branch in the target repository. 1. Basic support for `git send-mail` format - `[PATCH 2/3]` with patch as content rather than attachment https://gitlab.com/gitlab-org/gitlab-ce/issues/53552 The original way to share changes from one Git user to another. 1. Support for forking workflows It should be possible to create a merge request on the upstream project but without a pre-existing fork. 1. Support for multiple versions like `[PATCH v2 1/2]` which is kind of like force pushing a new version 1. Add support for this via REST API Email is fine for sharing contributions into the public realm, but creating merge requests from private instance to private instance necessitates using an encrypted transport layer. #### Merge requests between GitLab instances https://gitlab.com/gitlab-org/gitlab-ce/issues/47191 Wrap the core email workflow in a simple API, and add support to the merge request interface to **Publish** rather than **Merge** a merge request. - select target upstream project on a GitLab by pasting a URL to the upstream project, and GitLab will detect if it's a GitLab server that supports the new API #### Merge requests from GitLab to GitHub.com This should be the same workflow, but will need to make use of GitHub APIs. - select target upstream project on GitHub.com (e.g. `vuejs/vue-router`) - GitLab checks if there is a merge base - fork the target upstream project on GitHub.com (e.g. `jamesramsay/vue-router`) - push changes from GitLab to my fork on GitHub.com - open merge request from my fork to the upstream target Ideally it would be possible to avoid the extra fork. #### Merge requests from GitLab to BitBucket etc TBD ### Links / references - https://www.scuttlebutt.nz/applications#git-ssb