I've been thinking about this a lot lately as well but from a different vantage point. I put together an "ast-crdt" project combining Abstract Syntax Tree and Conflict-free Replicated Data Types) which allows multiple agents to effectively merge multiple code changes. The initial thought was to answer the question "what would it look like to allow modifications to the same code project by multiple agents in a safe way without relying on git semantics (and the inevitable merge conflicts)?" It also touches on the idea of "what if humans are removed entirely from the commit-PR-merge workflow?" All of this to say git-centric forges as we think about them today would start to look very different.
If I could make my own GitHub
111–120 of 160 posts
Re: If I could make my own GitHub
#112Earlier quoted context omitted.
Either the code gets merged or it does not. That's the inherent boolean part. Given that, what's wrong with simply commenting on the PR to document the concerns, issues, lack of knowledge, etc? Unless you're using those +/-2 to achieve some sort of goal... but you can also do that with labels, tags, etc. on the PR.
> Either the code gets merged or it does not. That's the inherent boolean part. In many environments that depends on more than just code review, e.g. CI.
Sure, it depends more than code review, but the code review is still a boolean flag, i.e. BOOLEAN getsMerged = codeReview && passesCI && passesTests....
Unless you're implying codeReview is a score and a low code review score can be offset by higher scores elsewhere eg. passes more tests?????
Re: If I could make my own GitHub
#113> Well Y Does Some Of That yes but tangled.org really does do most of that! 1. JJ as the VCS: tangled supports stacked PRs using jj change-ids. https://blog.tangled.org/stacking , we use it a lot to build tangled itself: https://tangled.org/tangled.org/core/pulls 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…
Both Radicle and Tangled miss the point; these are all for public collaborative work, but what about private repos? Many users work on side projects; they use GitHub private for this. Once you learn GitHub, then you also start public projects on GitHub. The point I am trying to make is, until you offer a user the ability to make a private repo for side projects, it's unlikely to take off. What people want is the abil…
That's a bit selfishly-expressed.
Private repos provide nothing to the site by definition. The value model here is, you must pay for private repos, either by paying a subscription or hosting your own node and bearing the related costs.
Re: If I could make my own GitHub
#114Does this conversation exist in 2026? If we can all code everything quickly and SaaS has no value then just build your own in a weekend and put GitHub out of business? There is a fundamental contradiction here.
No one wants to do it-- but it's foundational.
It's also very hard to appease everybody; from visual design to operational smoothness.
Re: If I could make my own GitHub
#115I'm likely wrong but this person seems to be talking about fossil-scm...
Re: If I could make my own GitHub
#116I don’t understand why any of this would take submarine money to build. GitHub itself certainly wasn’t built with submarine money.
It doesn't need a lot of money, but it needs some absolutely gifted UX designers.
This, seriously.
The backend could be git on an SSH server, but if you have a slick design and 100% operational uptime-- you'll capture 80% of the developers using Github currently.
Re: If I could make my own GitHub
#117Earlier quoted context omitted.
What if you want someone to look at a portion of it but they don't know enough to approve the whole thing. They give +1 Someone else knows the other portion well and sees the +1 and decides to +2. In practice this ends the stalemate where partial owners don't feel confident to approve the whole thing
The PR needs to have someone who knows the whole thing. Having several people review each separate parts but not understanding the others' can cause interaction bugs. If such bugs cannot happen (say, due to modularity, or type safety guarantees etc), then it won't be the case where you need to have a partial approve. I am not a fan of partial approve. Either you think the code is approvable, or it isn't.
Domains of expertise are a thing. E.g. Google had "readability" which was the code style and opinioned language expertise that one person might have even without the deep system knowledge for a PR.
You can require approvals from N domains from (potentially) different people.
Re: If I could make my own GitHub
#118Does this conversation exist in 2026? If we can all code everything quickly and SaaS has no value then just build your own in a weekend and put GitHub out of business? There is a fundamental contradiction here.
Github is an ecosystem and its biggest moat is the number of people that use it.
To make a replacement, not only do you have to improve on support for every major use case at a technical level (no easy task, to put it mildly), you also have to make it so compelling to use that Github users will abandon Github en masse.
Someone with an LLM assisted IDE has the theoretical potential to improve on all major Github features. But to make their replacement compelling enough to get folks to leave Github? Not a chance.
Re: If I could make my own GitHub
#119Very nice thoughts that I've not thought of before. I especially like the fact to have PRs and issues offline.
That was a nice read having my first of May beer.
Re: If I could make my own GitHub
#120Earlier quoted context omitted.
It doesn't need a lot of money, but it needs some absolutely gifted UX designers.
This, seriously. The backend could be git on an SSH server, but if you have a slick design and 100% operational uptime-- you'll capture 80% of the developers using Github currently.
I think that's incredibly optimistic to the point of unrealism.
Github, outages and all, is a known commodity with a reputation they can make money off of.
Any replacement would have to offer not just compelling feature improvements and uptime, but to have a history long enough to make it trustworthy to migrate to.
And uptime? Easy when you have a small number of customers. Much, much more difficult at a million+ customers (although Microsoft has really dropped the ball).