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

> PR approval is too boolean. The PR is approved or it's not approved. Real code review, like real life, lives in the middle

This is have-your-cake-and-eat-it. PR approval is a permission so is a boolean. Of course it is. Either the code can be merged or it can't.

What's being described really here is just something to make you feel slightly better about yourself whilst approving code you hate ("we should revisit this..."). Just open a new ticket.

> If I clone a repo, I want a pretty limited history for that repo when I clone. If I start to go back in time, spin up a worker to go fetch that stuff from the VCS when I need it.

You want blobless clones:

    git clone --filter=blob:none <url>

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.

I'm likely wrong but this person seems to be talking about fossil-scm...

> There are a lot of tools that do parts of this. I want someone to take them, put them all together and fit them up.

But just a few inches earlier, the author stated:

> Everything tools always turn into crap.

This seems like a contradiction to me.

I think there's a gap in the market for a much simpler type of git service. All I need is a remote host to which I can push projects for others to see. I don't particularly want pull requests, actions or anything like that.

Maybe a way of facilitating "releases" with compiled binary assets (built locally and uploaded).

Forks can be handled by people cloning the repository and uploading a new project.

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

> Stuff happens in the wrong order.

Seems like there are lots of answers: pre-commits, rebase squashes, merge squash...

    git commit --no-verify
    git commit --amend --no-edit

I would use RFC2822 as the underlying format to store any kind of message (pull request, review comment, issue etc.), and of course when displaying messages use CommonMark to style them. Any metadata goes into headers, and Message-ID/In-Reply-To/References headers can be used to link them all together. Using this well defined format you can then decide how to best store and transport all the messages, maybe in a git repo as well, use email, or whatever else works.

I personally think Gerrit works much better than whatever GitHub et al. have for code reviews. As for CI, I would try to keep that out of it as much as possible; just hooks to start a pipeline and to display the result and decide whether to allow a merge or not.

> This person has a family. This person has hobbies. This person is, at this moment, crying.

Reminded me one benefit of email-based workflow.

If I started receiving email, that's usually because I'm in the right mood to doing so. In such mood, I'll be more focused because I expect nothing else to interrupt my work.

My problem with notification is that there's a pull towards clearing them as they show up. But there's no guarantee I have the right energy at the moment.

Also, I found that most notification systems on the web are poor mimics of what email client has already archived decades ago. Maybe the old folks really got it right for using emails.

If i was making my own GitHub, i would make it possible to put one deploy keys to multiple repos, same as in Gitea. Why that doesn't work is beyond me and is a major pita with no simple work arounds

I don’t understand why any of this would take submarine money to build. GitHub itself certainly wasn’t built with submarine money.

Working on it :P I’m going to take the idea to add a ‘defer’ button to PR comments. Which is fantastic.

If anybody here does do this -- and please do -- please abstract out the VCS backend so we're not stuck with git. Let people bring their own CI/CD too. If you must roll your own CI don't use YAML, for mercy's sake; use a declarative definition (a la bazel with CUE, Skylark) or actual code.

If gitlab makes even some of its current premium features free (mostly around push rules, and merge dequest guardrails), most comoanies will host their own gitlab in a heartbeat.

Mostly agree with everything, but I will not stand for this slander against sweet potato fries!!!

I dream of a world of stagit + issue creation written in Rust. End

> Let me do an enforced pre-commit hook to run the jobs remotely on the forge and provide the feedback to the user before they push.

You have to 'push' the code to the forge to run it. This code is a 'branch' of the version that is on repo.

> The PR is approved or it's not approved

The code is either merged or it's not. Sure you can trivially add a snooze feature...

> I don't need 4 eyes on every change, especially in a universe where LLMs exist.

Huh, I do. Anyone thinking LLMs replace human review, when LLMs are already replacing the coders, is just vibe-coding, not building a reliable library.

> Stacked PRs are just better.

I have no idea what this really means honestly. You can stack multiple commits in a single PR. You can create PRs based on other MRs.

> A forge shouldn't do everything. Issue tracking yes. Kanban board, probably not.

The board has to live in-sync with the issues or it's not a board.

If I were starting such a project -- and I must resist the temptation to do so -- I'd start by taking a very close look at Gerrit.

As a technology base to fork from, probably not ideal. But its flows are something to learn from.

The PR process in GitHub has always been garbage, and its cargo cult adoption by the whole industry is sad. But also unnecessary. There were always alternatives, but GH's refusal to do proper multi-round review and its tendency to encourages giant messy merge commits with no ability to track discussions between changes is an organizational nightmare, and now with LLMs it's even more terrifying.

Every company I've worked at since I left Google has had this problem with giant "take it or leave it" submissions. Dozens of commits in one "review". No ability to properly track changes between revisions. A mess of commits that all land at once.

I don't see how one can build a serious software team structure over top of this. It's a mess. And GitLab only makes it slightly better.