Hacker News Reader

Comment by remram | Hacker News Reader

As far as I'm concerned, the first platform to get federated merge requests will win it all.

Federated merge requests, wiki, issues and such would be a killer feature.

I want to see all this data for all of the forks that are relatively close together from a single pane of glass. This would make collaborating and uplifting code back to the main branch much easier for small free software projects.

Can you elaborate on what that means and how it improves repos?

Currently, if a repo is on github, and you develop a patch on a fork on gitlab, you can't just click a button to open a pr, the way you could of both upstream and fork were using the same provider. Federated PRs would be the capability for one provider to "talk" to another to be able to pull your patch from the other provider.

Being able to host software on my own instance, without requiring everybody else to sign up there to contribute.

I like to self-host, but I don't want to be sysadmin to a public service, and deal with account deletion, password resets, ...

Merge requests are already federated on any platform using Git, just email an author.

Email is federated, but I don't see how that means "any platform using Git" now has federated merge requests?

You email the author, the author can merge your patch or pull from your repo/branch.

Merging your patch even comes built-in with Git. The place hosting your Git repo doesn't need anything special to support this. You email the author, they merge your patch and then git push.

By this definition, everything is federated, because you can email the author and ask them to post something for you.

Except with git this is all built into the git client out of the box. Git has built-in tooling for sending patches over email and applying emailed patches. It's not something bolted on top, people have collaborated on git repos this way for ages.

Some other federation method through centralized platforms like Github would have to be bolted on to git, email is just the built-in and very much intended method that already exists.

What you're now saying is that "Git has federation features for patches" which doesn't relate at all to your earlier claim "Merge requests are already federated on any platform using Git".

A "merge request" or "pull request" is a specificb thing on those platforms (GitHub/GitLab/Gitea/...) and are definitely not federated.

In the same way, Twitter is not federated just because it runs on phones where you could send your message via SMS instead. That makes no sense. Even if SMS is built into your mobile text editor.

A merge request is a series of bundled commits layered in a web database somewhere to break compatibility with vanilla Git workflows. That's why Gerrit is better if federation/portability is valuable. 1 commit = 1 code review.

You can push a commit to Gerrit for the webui, you can email it to someone for manual code review and merging, you can (maybe) do it in Phabricator, so on and so forth.

This is inherently federated in a way that GitHub's pull request system does not. A commit in GitHub requires context in the form of a "pull request" provided by their proprietary interface and so the raw git commit doesn't have everything you need to perform the review.

Apologies for not communicating this better in my original comment.

Have a look at GitLab's plans then: https://docs.gitlab.com/ee/architecture/blueprints/activity_...

Edit: Better link

There are many plans

Reply on news.ycombinator.com