Support federated pull requests #184
Comments
|
From @roblabla on May 25, 2016 12:9 Somewhat related : gogs/gogs#2210 |
|
This is the number one feature for a personal hosted Git service! |
andreynering
added
type/feature
|
This could be integrated with git-appraise integration too ? |
|
@ekozan formal proposals are welcome, but I do see git-appraise integration could be a good companion for federated pull requests (to basically have reviews travel across federated nodes with the rest of the code, right?) |
|
@bkcsoft maybe you can help with keeping the GitLab specs open enough to allow for federating PR between GitLab and Gitea too ? |
|
@strk I could steer it in the direction of just sending patch-files between servers (maybe using webhooks?). Which is what I suggest Gitea should do as well. Makes it really easy not having to push/pull between servers :) |
|
Well, seems like they're already thinking or using |
https://gitlab.com/gitlab-org/gitlab-ce/issues/4013 is tagged as |
|
@bkcsoft We might take the lead here :) If we can get GitLab and GitHub on board, that would end the locking currently imposed by these platforms |
I can't believe that GitHub wants to solve the lockin issue :P |
|
No but if other platforms lead the way, people might demand they follow. And people might migrate :) Software like Gerrit kind of allows for that |
|
@stevenroose do you have reference about the Gerrit support ? |
|
If we implements Gerrit, could we invite Golang team to use Gitea? 😄 |
|
@strk With Gerrit, you package your commits using |
|
You'd still need write permissions to the repo to push those
reviews to the ref, right ?
In that case the missing bit would still be eventually tracking
a different repo holding the review ref ?
|
|
Yeah it is different. It pushes individual bits with write permission. With federated PRs, Gitea should periodically (or on request) check the branch reference for new changes. |
|
AFAIK, git request-pull does not use git commits at all. It merely generates a list of commits between local and remote, and print it on stdout. We'd need to specify a way to send those changes to remotes/to pull them from remotes Git request-pull is part of the standard git install though, unlike git appraise or git review. |
|
@roblabla Yeah the flow would be to save the |
|
Unless I'm missing something `git request-pull` references a specific commit,
while github/gitea pull requests reference a (possibly moving) branch.
Do we want federated request to track branches rather than specific commits ?
I think we do want a PR (thread of comments/discussion) to track a branch.
|
|
it references specific commits yes. So we'd need to continuously re-fetch the data 😒 |
|
On Tue, Dec 20, 2016 at 12:20:34AM -0800, bkcsoft wrote:
it references specific _commits_ yes. So we'd need to continuously re-fetch the data 😒
We can only fetch new commits if we have a reference to a branch name,
which is not in `git request-pull` output. So if we want to keep the
`track-a-branch` approach, we cannot rely on `git request-pull`.
A PR creator could ask for a remote URL and a branch name, check out the
remote branch locally, perform some checks (ie: refuse to create PR with
a huge number of changes), and create the PR.
Then a button and a webhook could be then made available to fetch more
commits, if any, from the remote branch. Only the PR author should be
given the ability to request updates. Placing a git hook on his fork
to hit the destination webhook would make the update experience smoother.
…--strk;
|
|
I would suggest that when creating a PR as a guest account, you'd have a tab with "external" or "federated' or whatever that has two options:
In the latter case, once the PR is created, users should be able to overwrite their previous file in order to change the commits in the PR. Also, in the case of unavailability of automatic branch updates, you could require a user to manually trigger a refetch. In almost all of the cases, users commit to a PR'ed branch exclusively in the light of the commit, so they can just refetch whenever to update the branch. (Take into account that often, updates to a commit are because of feedback in the PR, so they have the page open anyway.) As my thesis promotor put it: "The real opposition to a change does not come from people who are against it but from people who keep saying it's not enough." |
|
I don't think this feature usefull, you can add two remote for this case. for example branch github for gh, master for gogs, I use both in my work with one repository. and git review is another things. don't make big feature to solve little problem. |
|
@renothing I don't think you fully understand the proposal. It has nothing to do with being able to compare or checkout code from different remote sources. Instead, it is about allowing people to submit pull requests or patches without having to be registered to your system. If I publish a piece of software on my Gitea instance, I want others to be able to create a PR without requiring them to go through the hassle of registering, forking, pushing their changes to my instance and then creating a PR. |
|
How about asking GH / GL for their feedback on a proposed standard? Could be an opening into a wider discussion on the subject |
|
Sure, but we need that proposed standard first ...
|
Merge changes from upstream
|
Pagure (https://pagure.io/pagure) system supports remote pull request, which I found useful while working on Fedora packages repository. You do need to be registered to make a remote pull request. See: https://docs.pagure.org/pagure/usage/pull_requests.html#remote-git-to-pagure-pull-request |
|
Related: gogs/gogs#4437 |
|
Any news on this? There is currently a lot of news coverage about Github being acquired by Microsoft, so federation in context of a git web-service would be super cool :) |
|
I literally just came search for this issue a minute before I saw the notification from your comment. This (and federated pull requests) is really the killer feature for the next Git platform. I see an OpenID login tab, but it's not very user friendly with regards to easy access to the big OpenID providers like Google. I only saw an exception made for GitHub. |
|
Hi everyone. I found this issue while looking around what was being done on the subject of federated git infrastructures, following the buying of GitHub by Microsoft. When it comes to federating user identities, comments, activity… and I guess pull / merge requests as well, I think doing it using the ActivityPub standard would do even more than just federating git infrastructures together: it'd federate git infrastructures with other ActivityPub implementations. For example, it might allow you to comment pull request on a Gitea instance from a Mastodon instance, to follow-up on a bug report within a video on a PeerTube instance or a slide deck on a MediaGoblin instance with a ticket on a GitLab instance… My 2 cts ;) |
|
Chiming in to what @Arkanosis wrote: seems like that's what GitPub aims at. Maybe some Gitea devs chime in there? That's what's currently asked for:
|
|
I'm not sure if @Arkanosis comment would also apply to Diaspora but it would definitely be useful for myself if it was the case! Looking forward to this feature! :) |
@KingDuckZ: I wish! The last time I checked, Diaspora wasn't implementing ActivityPub, though. I'd really like it to do so to federate with other networks (especially with Mastodon). That would, as an added benefit, make it much easier to federate Diaspora and whatever comes out of this proposal (GitPub or anything else). Sure, it'd be possible to federate directly with Diaspora using the diaspora federation protocol (webfingers + microformats + others), but this protocol does not seem to get as much traction as ActivityStreams / ActivityPub. |
|
Please stay on topic. This issue is only related to being able to open pull requests from remote repos. All that is needed to achieve this is a common formulation of "repo and branch". An example would be Federation of other data like issues and comments are out of the scope for that. I think as a first step, you should be able to make a PR without creating an account on a git repo. |
|
@stevenroose if you refer to me: apologies, I should have better placed it in #1612 indeed. Meanwhile someone else did mention it there. |
|
There now exists a working group/ project for designing a ActivityPub based git federation protocol. https://github.com/git-federation/gitpub Join their mailing list if you're interested. |
|
GitLab is implementing it! |
|
Niiiice! |
|
Federated git would be awesome. Don't like to register uncountable accounts for git repos... |
|
@pwFoo i think it will take some time to specify and implement this.
Would it be an option for you to "Login with GitHub" when it's just one click until then? |
|
Could be an workaround, but goal should federated issues / PRs, federated social networks (mastodon, pleroma, misskey, ...) in the future. |
What's the use case of this? Squishing gitea to forcefully share information between ActivityPub platforms and GitFed or whatever solution is built here would lead to overengineering. |
|
@jalcine The use case is that if you work on multiple different software projects, you're not required to create & maintain an account on all the platforms these projects are hosted on (GitHub, GitLab or their own self-hosted Gitea/GitLab/whatever). Ideally you have your own repo (GitHub, GitLab, or your own custom Gitea) and you can make PRs to all of the projects your work on from your own repo. |
|
Right but what the person I was replying to was saying that you'd sign in using Mastodon to Gitea? |
|
In my case, I have a Gitea instance on a home server. My raspberry pi and my internet connection has limited resources. And I want to prevent that bots can created accounts so that I have less administration in my free time. Because of that, I disabled the registration page. Thus, nobody is able to add issues to my public repositories. Currently, the only way to get issues from people is using a mirror repository on Github. But then, I can close my Gitea instance. The only way where Gitea will be better than Github is that it supports federated issues and pull requests (principle of decentralization). Social networks like mastodon is another topic and nice to have. But federated issues and pull requests is a must-have so that people don't need to worry about account creation at each instance, like Nextcloud/Owncloud. |
|
@jalcine Goal is not to login with GitHub or Mastodon Account... I quoted my answer. |
|
I've locked this issue as it is being currently discussed in the forgefed mailing list please redirect all conversation there. More info: https://github.com/forgefed/forgefed |
and others
From @stevenroose on May 25, 2016 11:24
Currently, users can only make pull requests if they have an account on the same Gogs instance. It should also be possible to make pull request from external repositories like GitHub or other Gogs/GitLab repo's.
This could be integrated with gogs/gogs#1297 and gogs/gogs#3130.
Copied from original issue: gogs/gogs#3131
The text was updated successfully, but these errors were encountered: