you can self-host components of tangled too: the git hosts (called "knots") and the CI runners (called "spindles"). the only difference between tangled and gitea is that with tangled, repos on your own servers are visible and discoverable via tangled.org, and users on other instances can submit PRs/issues stars etc. nix modules for all services are provided.
2. Raspberry pi as a forge for a long time: also check, the git server shim is super lightweight, its just an XRPC layer over git repositories + an sqlite3 database. there are folks running it on a riscv board with 512 megs of RAM.
3. Actions are critical and they should be runnable on my local machine: IMO this ask is slightly misplaced. it is mostly your build-systems' job to be hermetic, run anywhere, handle cross-builds etc. it would be really cool to "promote" results of such builds to the forge itself.
i am unable to access any repository on that website. for some, it complains that ssh or https URLs are not supported by my browser? and for others its just loading indefinitely with `Failed to load file tree`. maybe its not fairly mature.
its linked in the original post as well, but here is an explanation of why activitypub is not a good fit for this problem, by the authors of ForgeFed themselves: https://forgefed.org/blog/actor-programming/
maybe, but tangled knots actually federate. you could contribute to repos on knot.ghostty.org and knot.tangled.org with the same account. no other platform permits one identity across instances.
yes, thats right! when you submit a branch, you can choose to "stack" it, so the individual commits in the branch turn into separate PRs. these PRs evolve individually, can be merged individually, and be reviewed individually. you can also set different reviewers/labels for different PRs in the stack.
have a longer write up here: https://blog.tangled.org/stacking but we have "interdiffs", to view a delta from previous review. pull-requests advance in the form of immutable rounds much like the patch workflow on email.
- the first PR in the stack creates a search index.
- the second one adds a search API handler.
- the last few do the UI.
these are all related. you are right that you can do this by breaking a change into commits, and effectively that is what i do with jujutsu. when i submit my commits to the UI, they form a PR stack. the commits are individually reviewable and updatable in this stacking model.
gh's model is inherently different in that they want you to create a new branch for every new change, which can be quite a nuisance.
tangled.org supports native stacking with jujutsu, unlike github's implementation, you don't need to create a new branch per change: https://blog.tangled.org/stacking/
there's https://forgefed.org/ defined by the creators of forgejo. there is no complete implementation of the spec. from the last forgejo changelog, the "star" action has been completely federated. federated PRs and issues are a long way away.
https://tangled.sh is the other contender in this space that I know of. uses atproto (same as bluesky) under the hood.
fundamentally activitypub is insufficient to define these kind of networks. you'd need to have some sort of object-capability representation. the creators of forgefed are also moving in this direction: https://codeberg.org/Playwright/playwright
the only thing I really miss from GitHub is the social bits. it's super easy to stand up cgit etc. but you miss out on actual collab features, discover etc.
I've moved the bulk of my repos from GitHub to cgit first, but now to https://tangled.sh.