Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support federated pull requests #184

Open
stevenroose opened this issue Nov 16, 2016 · 70 comments
Open

Support federated pull requests #184

stevenroose opened this issue Nov 16, 2016 · 70 comments

Comments

@stevenroose
Copy link

@stevenroose stevenroose commented Nov 16, 2016

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

@stevenroose

This comment has been minimized.

Copy link
Author

@stevenroose stevenroose commented Nov 16, 2016

From @roblabla on May 25, 2016 12:9

Somewhat related : gogs/gogs#2210

@stevenroose

This comment has been minimized.

Copy link
Author

@stevenroose stevenroose commented Nov 16, 2016

This is the number one feature for a personal hosted Git service!
Would be even greater with #185 !

@ekozan

This comment has been minimized.

Copy link

@ekozan ekozan commented Nov 16, 2016

This could be integrated with git-appraise integration too ?

@strk

This comment has been minimized.

Copy link
Member

@strk strk commented Nov 17, 2016

@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?)

@tboerger tboerger added this to the 1.x.x milestone Nov 24, 2016
@stevenroose

This comment has been minimized.

Copy link
Author

@stevenroose stevenroose commented Nov 28, 2016

GitLab is tracking this issue here, so maybe you could word out a streamlined workflow. They are planning to mention the feature during their summit.

@strk

This comment has been minimized.

Copy link
Member

@strk strk commented Nov 28, 2016

@bkcsoft maybe you can help with keeping the GitLab specs open enough to allow for federating PR between GitLab and Gitea too ?

@stevenroose

This comment has been minimized.

Copy link
Author

@stevenroose stevenroose commented Nov 29, 2016

@strk is @bkcsoft affiliated with GitLab?

@bkcsoft

This comment has been minimized.

Copy link
Member

@bkcsoft bkcsoft commented Nov 29, 2016

@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 :)
@stevenroose Yes

@bkcsoft

This comment has been minimized.

Copy link
Member

@bkcsoft bkcsoft commented Nov 29, 2016

Well, seems like they're already thinking or using git request-pull -p (which sends the patch along) so it should be cross-platform compatible 🙂

@bkcsoft

This comment has been minimized.

Copy link
Member

@bkcsoft bkcsoft commented Nov 29, 2016

They are planning to mention the feature during their summit.

https://gitlab.com/gitlab-org/gitlab-ce/issues/4013 is tagged as moonshot, unassigned, no milestone and no MR in sight. So maybe not get your hopes up just yet 🙂

@stevenroose

This comment has been minimized.

Copy link
Author

@stevenroose stevenroose commented Nov 29, 2016

@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

@tboerger

This comment has been minimized.

Copy link
Member

@tboerger tboerger commented Nov 29, 2016

@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

@stevenroose

This comment has been minimized.

Copy link
Author

@stevenroose stevenroose commented Nov 29, 2016

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

@strk

This comment has been minimized.

Copy link
Member

@strk strk commented Nov 29, 2016

@stevenroose do you have reference about the Gerrit support ?

@lunny

This comment has been minimized.

Copy link
Member

@lunny lunny commented Nov 30, 2016

If we implements Gerrit, could we invite Golang team to use Gitea? 😄

@stevenroose

This comment has been minimized.

Copy link
Author

@stevenroose stevenroose commented Nov 30, 2016

@strk With Gerrit, you package your commits using git-review and push them to a certain ref and it will show up in Gerrit as a code review. No need to create a Gerrit fork. It does not use git request-pull though.

@strk

This comment has been minimized.

Copy link
Member

@strk strk commented Nov 30, 2016

@stevenroose

This comment has been minimized.

Copy link
Author

@stevenroose stevenroose commented Nov 30, 2016

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.

@roblabla

This comment has been minimized.

Copy link
Contributor

@roblabla roblabla commented Nov 30, 2016

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.

@stevenroose

This comment has been minimized.

Copy link
Author

@stevenroose stevenroose commented Dec 18, 2016

@roblabla Yeah the flow would be to save the git request-pull to a file and upload that (like how submitting patches used to work in the past). Or either enter a URL to a branch of a remote repo so that Gitea can update the PR.

@strk

This comment has been minimized.

Copy link
Member

@strk strk commented Dec 19, 2016

@bkcsoft

This comment has been minimized.

Copy link
Member

@bkcsoft bkcsoft commented Dec 20, 2016

it references specific commits yes. So we'd need to continuously re-fetch the data 😒

@strk

This comment has been minimized.

Copy link
Member

@strk strk commented Dec 20, 2016

@stevenroose

This comment has been minimized.

Copy link
Author

@stevenroose stevenroose commented Dec 20, 2016

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:

  1. a text input field for a branch URL, with a "fetch" or "test" button maybe to check for reachability and availability of tracking

  2. a file upload field to upload a .diff, .patch file or the output of a git-request-pull; this might also be a textarea

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."

@renothing

This comment has been minimized.

Copy link
Contributor

@renothing renothing commented Jan 3, 2017

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.
anyway, gogs focus on small business or self hosting. not for public cloud service.

@stevenroose

This comment has been minimized.

Copy link
Author

@stevenroose stevenroose commented Jan 4, 2017

@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.

@stevenroose

This comment has been minimized.

Copy link
Author

@stevenroose stevenroose commented Mar 22, 2017

I agree with @strk. Git itself is quite powerful, I would try to resort as much as possible to core Git functionality.

If federation is implemented f.e. based on Git URI's, adding UI sugar for hosting providers is not that hard. For Gitea, we use our own API's to extract information from the PR. For GH/GL/... we can either not support them, so just support copy-paste Git URI's, or implement a UI widget to retrieve these URI's from the API's. Or even simpler, map PR URL's to Git URI's.

One issue is that there is no standard way to represent a branch in a remote repo, as far as I'm aware. I think that I saw git://provider/repo.git#refs/mybranchref before, but I'm not sure how standard that is.

@strk

This comment has been minimized.

Copy link
Member

@strk strk commented Mar 22, 2017

@sbrl

This comment has been minimized.

Copy link

@sbrl sbrl commented Mar 24, 2017

How about asking GH / GL for their feedback on a proposed standard? Could be an opening into a wider discussion on the subject

@strk

This comment has been minimized.

Copy link
Member

@strk strk commented Mar 24, 2017

ethantkoenig pushed a commit to ethantkoenig/gitea that referenced this issue Jun 1, 2017
@davidlt

This comment has been minimized.

Copy link

@davidlt davidlt commented Oct 12, 2017

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

@link2xt

This comment has been minimized.

Copy link

@link2xt link2xt commented Jan 8, 2018

Related: gogs/gogs#4437

@vanitasvitae

This comment has been minimized.

Copy link

@vanitasvitae vanitasvitae commented Jun 4, 2018

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 :)

@stevenroose

This comment has been minimized.

Copy link
Author

@stevenroose stevenroose commented Jun 4, 2018

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.

@Arkanosis

This comment has been minimized.

Copy link

@Arkanosis Arkanosis commented Jun 4, 2018

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 ;)

@IzzySoft

This comment has been minimized.

Copy link

@IzzySoft IzzySoft commented Jun 6, 2018

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:

A specification like this must be agreed upon by at least some of Git web service implementations. If you are a developer of such a software, please join our discussion and speak up. We'll simply add you to the work group.

@KingDuckZ

This comment has been minimized.

Copy link

@KingDuckZ KingDuckZ commented Jun 6, 2018

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! :)

@Arkanosis

This comment has been minimized.

Copy link

@Arkanosis Arkanosis commented Jun 6, 2018

I'm not sure if @Arkanosis comment would also apply to Diaspora

@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.

@stevenroose

This comment has been minimized.

Copy link
Author

@stevenroose stevenroose commented Jun 6, 2018

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 https://github.com/go-gitea/gitea.git#federated-prs.

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.

@IzzySoft

This comment has been minimized.

Copy link

@IzzySoft IzzySoft commented Jun 6, 2018

@stevenroose if you refer to me: apologies, I should have better placed it in #1612 indeed. Meanwhile someone else did mention it there.

@schmittlauch

This comment has been minimized.

Copy link
Contributor

@schmittlauch schmittlauch commented Jun 8, 2018

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.

@stevenroose

This comment has been minimized.

Copy link
Author

@stevenroose stevenroose commented Sep 9, 2018

@vanitasvitae

This comment has been minimized.

Copy link

@vanitasvitae vanitasvitae commented Sep 9, 2018

Niiiice!

@pwFoo

This comment has been minimized.

Copy link

@pwFoo pwFoo commented Nov 5, 2018

Federated git would be awesome. Don't like to register uncountable accounts for git repos...
Federated PRs and issues! 👍

@davidak

This comment has been minimized.

Copy link

@davidak davidak commented Nov 5, 2018

@pwFoo i think it will take some time to specify and implement this.

Don't like to register uncountable accounts for git repos...

Would it be an option for you to "Login with GitHub" when it's just one click until then?

@pwFoo

This comment has been minimized.

Copy link

@pwFoo pwFoo commented Nov 5, 2018

Could be an workaround, but goal should federated issues / PRs, federated social networks (mastodon, pleroma, misskey, ...) in the future.

@jalcine

This comment has been minimized.

Copy link

@jalcine jalcine commented Nov 5, 2018

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.

@stevenroose

This comment has been minimized.

Copy link
Author

@stevenroose stevenroose commented Nov 6, 2018

@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.

@jalcine

This comment has been minimized.

Copy link

@jalcine jalcine commented Nov 6, 2018

Right but what the person I was replying to was saying that you'd sign in using Mastodon to Gitea?

@DevelAngel

This comment has been minimized.

Copy link

@DevelAngel DevelAngel commented Nov 7, 2018

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.

@pwFoo

This comment has been minimized.

Copy link

@pwFoo pwFoo commented Nov 7, 2018

@jalcine
"Federated git would be awesome. Don't like to register uncountable accounts for git repos...
Federated PRs and issues! 👍"

Goal is not to login with GitHub or Mastodon Account... I quoted my answer.
Goal is to use one account (ideally my own) to open issues, reply to or open PRs.

@go-gitea go-gitea locked and limited conversation to collaborators Nov 7, 2018
@techknowlogick

This comment has been minimized.

Copy link
Member

@techknowlogick techknowlogick commented Nov 7, 2018

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.