Implement cross-server (federated) merge requests
By this, I mean, that one could clone a repository managed by GitLab, make it publicly available somewhere and then manually file a merge request for a particular branch on the forked repository.
This would play along awesomely with git's distributed nature, since it would allow collaboration across different GitLab servers or even to other services such as GitHub. You could e.g. fork a repository hosted on a company GitLab server to GitLab Cloud and still do merge requests.
We like the idea of Edward Bopp: "I think, the first step is to allow users to create merge requests from repositories with custom URIs. This would not require a lot of work in terms of creating a protocol and dealing with spam issues, since one does not really have to deal with the “other” server except for pulling from it." and are accepting merge requests for this.
Hi Eduard, thank you for proposing this. I've edited your suggestion to replace GitHub with GitLab Cloud to make it easier to achieve. Ideally this would depend on an open protocol that everyone including BitBucket and GitHub could adopt. We look forward to a world of federated git hosting.
Personally (Sytse) I think that it would be great if this protocol worked without having to configure the servers explicitly. It might be needed to have a user account on both servers so that SPAM can be prevented.
I think, the first step is to allow users to create merge requests from repositories with custom URIs. This would not require a lot of work in terms of creating a protocol and dealing with spam issues, since one does not really have to deal with the "other" server except for pulling from it.
A next step could be to implement automated forking to other servers. This is where one has to think about protocols and accounts.
Actually I would be interested in trying to do this myself but I have zero experience with both Ruby and the GitLab codebase. Let's see if I can change that…
Eduard, I like your idea of starting small by creating merge requests coming from repositories that are on a different GitLab server. Maybe an even smaller step is allowing you to fork projects from a different Gitlab server, but that can also be added later. Good luck with the implementation.
People https://twitter.com/Carols10cents/status/459753771807932416 suggested using OStatus http://status.net/wiki/OStatus for this.
The git way of doing a cross-server merge request is emailing the output of request-pull http://git-scm.com/docs/git-request-pull
Should we use some kind of DHT for self-discovery of repositories?
Mitar, for now we want to keep it simple with cross-server merge requests. A peer-to-peer GitLab with distributed hash table would be another feature request.
I agree that users should be allowed to submit a merge request from an arbitrary git url and branch. Git is meant to be distributed, it should not be bounded by a centralized service (such as GitHub, and the current GitLab). git-request-pull is great, but integrated with GitLab is even greater!
Well, the minimal solution would be a parser for the git-request-pull(1), which would check every comment and if recognized the comment as the pull request, it would add button for the owner of the repo (e.g., [Create Pull Request]). After pressing that (so it is constantly under the control of the owner repo), gitlab would setup new remote (if doesn't exist still), fetch it, and create a merge request.
Unfortunately, I cannot code Ruby to save my life (Pythonista here), so I will have to leave it to somebody else
Federation is SO important; one of the biggest problems with the modern Internet is that the web has become totally centralized; federation allows us to really be peer-to-peer, the way the Internet was built and the way Tim Berners-Lee envisioned the web. Bring the power back to individuals! As it stands now, people use GH because "everyone is on it." If GitLab supported federation, then everyone on a (public) GitLab instance would be "on it" as well.
GH's killer feature, facebook's killer feature? "Everyone's on it." Seriously, it's that important.
Re: spam, might be worth seeing how Google Wave & XMPP in general deal with this & federation. GNU Social (managed via GitLab, in fact) also supports federation; I suspect diaspora does too. There's a plethora of open source stuff out there to borrow the model from, and probably even some code. I haven't seen any ruby apps already using federation in my quick search, but here's a supporting library for the WS-Federation protocol: https://github.com/kbeckman/omniauth-wsfed
Or maybe it's as "simple" as building from an OAuth side or an OpenID side, (or both) depending on what the architechture should be like.
I really thinkl we should be thinking about this like XMPP.
The comment about OStatus is interesting; Laconica->Status.NET->GNU Social is one of the avenues of design that might be worth looking at, to me.
Erik van Zijst
Is there anyone who has a concrete plan for this and is ready/available to work on it?
In particular, some folks on this thread talk about the "simple" approach where one can input the URL to a remote repo when creating PRs. What would the full workflow here look like?
Federation PRs would be great if they worked across different vendors (e.g. GitHub <--> GitLab), but you could start by just federating between different independent GitLab servers. What is the current status around this idea?
Full workflow with the simple approach would be:
- You have an account on the destination web server
- Go to https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/new
- In the first input field of the source branch field put in the url of a public git repo
- Click compare branches
Erik van Zijst
Some of the questions that I have around this proposal is how it would deal with permissioning. Would this only be supported for source repos that are public?
What would the PR page show? In order to show a diff, the dest server would have to go and fetch from the source. This can be very expensive and so it should anticipate not being able to immediately show anything on the create-pr page.
Would the dest server periodically re-fetch from the source to stay up to date?
I'm not too familiar with GitLab's PR workflow, but on GitHub and Bitbucket PRs are created from within the source repo. This proposal reverses that.
Would the fetched branch actually be brought into the dest repo? What if it clashes with an existing branch (e.g. pull "develop" from source, while the dest already has a "develop"), or would it create a temporary ref under something other than refs/heads?
This proposal would only be for public repo's.
I agree the fetch from the source would be slow.
Refetching periodically is not doable I agree.
Maybe we should explore a push alternative (instead of the pull we discussed above).
- Click create PR/MR
- Select a repo on another server (a server that you have OAuth access to)
- Source server posts a JSON file to destination server
- User is redirected to destination server and finishes the PR/MR
- Source server reports the JSON file to the destination server on updates