upvote

points

by JoshTriplett6 hours ago |
comments
upvoteby holysoles5 hours ago|
next
[-]
For those curious, the federation roadmap is here: https://codeberg.org/forgejo-contrib/federation/src/branch/m...

I'm watching this pretty closely, I've been mirroring my GitHub repos to my own forgejo instance for a few weeks, but am waiting for more federation before I reverse the mirrors.

Also will plug this tool for configuring mirrors: https://github.com/PatNei/GITHUB2FORGEJO

Note that Forgejo's API has a bug right now and you need to manually re-configure the mirror credentials for the mirrors to continue to receive updates.

reply
upvoteby mikepurvis5 hours ago|
prev|
next
[-]
GitLab has been talking about federation at least between instances of itself for 8+ years: https://gitlab.com/groups/gitlab-org/-/epics/16514

Once the protocols are in place, one hopes that other forges could participate as well, though the history of the internet is littered with instances where federation APIs just became spam firehoses (see especially pingback/trackback on blog platforms).

reply
upvoteby bsimpson5 hours ago|
prev|
next
[-]
I use GitHub because that's where PRs go, but I've never liked their PR model. I much prefer the Phabricator/Gerrit ability to consider each commit independently (that is, have a personal branch 5 commits ahead of HEAD, and be able to send PRs for each without having them squashed).

I wonder if federation will also bring more diversity into the actual process. Maybe there will be hosts that let you use that Phabricator model.

I also wonder how this all gets paid for. Does it take pockets as deep as Microsoft's to keep npm/GitHub afloat? Will there be a free, open-source commons on other forges?

reply
upvoteby debugnik1 hours ago|
parent|
next
[-]
> and be able to send PRs for each without having them squashed

Can't you branch off from their head and cherry-pick your commits?

reply
upvoteby bsimpson1 hours ago|
parent|
[-]
That's effectively what I do. I have my dev branch, and then I make separate branches for each PR with just the commit in it. Works well enough so long as the commits are independent, but it's still a pain in the ass to manage.
reply
upvoteby JoshTriplett4 hours ago|
parent|
prev|
[-]
Personally, I'd like to go the other way: not just that PRs are the unit of contribution, but that rebased PRs are a first-class concept and versioning of the changes between entire PRs is a critical thing to track.
reply
upvoteby rtpg1 hours ago|
prev|
next
[-]
I just want a forge to be able to let me push up commits without making a fork. Do the smart thing for me, I don't need a fork of a project to send in my patch!
reply
upvoteby okanat5 hours ago|
prev|
next
[-]
I would love git-bug project[1] to be successful in achieving that. That way Git forges are just nice Web porcelain on top of very easy to migrate data.

[1] https://github.com/git-bug/git-bug

reply
upvoteby pocksuppet5 hours ago|
prev|
[-]
So... git's original design
reply
upvoteby JoshTriplett4 hours ago|
parent|
[-]
No. Git is not a web-based GUI capable of managing users and permissions, facilitating the creation and management of repositories, handling pull requests, handling comments and communication, doing CI, or a variety of other tasks that sites like Codeberg and Forgejo and GitLab and GitHub do. If you don't want those things, that's fine, but that isn't an argument that git subsumes them.
reply
upvoteby shakna4 hours ago|
parent|
[-]
Git was published with compatibility with a federated system supporting almost all of that out of the box - email.

Sure, the world has pretty much decided it hates the protocol. However, people _were_ doing all of that.

reply
upvoteby JoshTriplett4 hours ago|
parent|
[-]
People were doing that by using additional tools on top of git, not via git alone. I intentionally only listed things that git doesn't do.

There's not much point in observing "but you could have done those things with email!". We could have done them with tarballs before git existed, too, if we built sufficient additional tooling atop them. That doesn't mean we have the functionality of current forges in a federated model, yet.

reply
upvoteby greyface-2 hours ago|
parent|
[-]
`git send-email` and `git am` are built into Git, not additional tools.
reply
upvoteby JoshTriplett2 hours ago|
parent|
[-]
That doesn't cover tracking pull requests, discussing them, closing them, making suggestions on them...

Those exist (badly and not integrated) as part of additional tools such as email, or as tasks done manually, or as part of forge software.

I don't think there's much point in splitting this hair further. I stand by the original statement that I'd love to see federated pull requests between forges, with all the capabilities people expect of a modern forge.

reply
upvoteby heliumtera1 hours ago|
parent|
[-]
What is a forge? What is a modern forge? What is a pull request?

There is code or repository, there is a diff or patch. Everything else your labeling as pull request is unknown, not part of original design, debatable.

reply
upvoteby JoshTriplett59 minutes ago|
parent|
[-]
Sorry to hear that you don't see the value in it. Many others do.
reply
upvoteby heliumtera29 minutes ago|
parent|
[-]
It's not what I meant.

GitHub style pull request is not part of the original design. What aspects and features you want to keep, and what exactly you say many others are interested in?

We don't even know what a forge is. Let alone a modern one.

reply