HN

Comments (147)

• Menu

  dust-jacket
  > PR approval is too boolean. The PR is approved or it's not approved. Real code review, like real life, lives in the middleThis 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.
• Menu

  nerdypepper
  > Well Y Does Some Of Thatyes 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/pulls2. 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.
• rererereferred
  > 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> Gets history and only fetches blobs on demand. Github has a great article on it https://github.blog/open-source/git/get-up-to-speed-with-par...
• Menu

  jacobwiseberg
  When the solution becomes the problem, an opportunity for disruption opens up. Lots of chatter around this right now. I'd be curious to see if any of the many alternatives popping up gain traction before Github course corrects.
• Menu

  JetSetIlly
  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.
• Menu

  ralferoo
  There's a good argument to be made that the data for reviews could be held in git repos just as easily as the source.It can be done incredibly easily simply by having a branch per review with a known prefix (although these will rapidly clog up the default branch namespace), implemented via git namespaces to be distinct from the main namespace, or maybe just a special branch e.g. ".reviews" that just contains commit IDs for the tip of each review branch.It just needs someone who's invested enough to specify it and make a viable implementation, after which people might start adopting it. I guess the reason github and the various forges didn't take this approach is that keeping the review metadata within their ecosystem is what gives their platform value. If anyone could use any local tool they like for reviewing other people's code, there wouldn't be as much vendor stickiness.EDIT: actually, I guess there are other reasons why you might want your review metadata in a different repository, such as access control and/or cross-repo reviews.
• Menu

  corvad
  I really like Gerrit's workflow with diff reviews as opposed to pull requests, but unfortunately compared to something like gitea it lacks everything else we've come to expect from git hosting (issues, project planning, etc) which makes it seemingly a hard sell for many. I really wish there was a nice diff review platform kind of like phabricator but alas.
• Menu

  gsliepen
  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.
• Menu

  nirui
  > 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.
• travisgriggs
  > 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.
• Menu

  kortamenbra
  I recognise myself in this post without having realised it previously.The PR review process is flawed, it adds something, but maybe not what it intends.
• kelvinjps
  Git can already do most of these with git hooks and for self hosting IIn a raspberry pi you only need git itself in the server and ssh. For example you can set a hook to run tests in the user machine, another to run in the server or deployments. I think people need to more about the options git already has
• thesurlydev
  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.
• Menu

  Dunedan
  > 1. Stuff happens in the wrong order. […] You don't want the feedback loop after the commit you want it before. 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.My approach is to utilize https://pre-commit.com/ to have all checks available to run locally during commit (or push), but leave it to contributors whether they want to run it or not. If they don't, the checks still run on the forge after pushing. The upside of this approach is that it still allows contributors to commit without internet access or the forge being down.> 3. PRs are too inflexible. I don't need 4 eyes on every change, especially in a universe where LLMs exist. The global GDP lost annually to senior engineers staring at a four-line PR waiting for someone — anyone — to type 'LGTM' could fund a moon mission.Well, that's possible with Github and is just a matter how permissions to merge PRs are configured. Just let every contributor merge changes without explicit approval. And if you want LLM approval, make that a Github Action with mandatory success for merging.> 4. Stacked PRs are just better. […]Seems like Github is working on this: https://github.github.com/gh-stack/> 8. On the flip side, since I need to be online all the time to really work with a team […]Sure, for communication you need internet access, but working on code can be much more efficient if you can do so without relying on internet access and the forge being available.I'd even argue working on issues and reviewing PRs should be available entirely offline too with just the state getting synced whenever internet connectivity to the forge is available.
• Menu

  afpx
  This article says git was designed for distributed version control. Then says git doesn't work for most distributed projects because there isn't high trust. But, I'm puzzled why people would still want to build software with low trust.
• mads_quist
  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.
• masa331
  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
• Menu

  Kwpolska
  > Stuff happens in the wrong order. You know the PR. Commit 1: 'Feature.' Commit 2: 'fix.' Commit 3: 'fix.' Commit 4: 'actually fix.' Commit 5: 'please.' Commit 6, made at 11:47 PM on a Thursday: 'asdfasdf'. This person has a family. This person has hobbies. This person is, at this moment, crying. You don't want the feedback loop after the commit you want it before. 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.How would a pre-commit hook help? Would the developer not be crying and working late if their work was rejected by the pre-commit hook instead of the PR? Also, if the tests are so fast they wouldn’t block the terminal running `git commit` for more than a minute or two, you can just run the tests on the local machine, and you should be running them as part of your workflow.> PRs are too inflexible. I don't need 4 eyes on every change, especially in a universe where LLMs exist. The global GDP lost annually to senior engineers staring at a four-line PR waiting for someone — anyone — to type 'LGTM' could fund a moon mission. A nice one. With legroom. Let me customize and more easily control this. If the person is a maintainer and the LLM says its low risk/no risk just let them go.You can do this with the existing forges, you can give trusted people the right to bypass the rules. Or you could build your own small PR auto-approval bot, which hands the diff to a LLM, and if the LLM approves, the bot approves the PR on the forge.
• ajkjk
  I love this style of post, independent of the content. For all of tech's ambitions I don't feel like the industries spends all that much time openly ideating on how to make a better world. People accept all sorts of things as normal that could easily be massively improved upon.
• steviee
  This makes total sense to me. Everything that makes up the state of your project should either be part of the versioned repo (git) or not be part of the project.I created a little Github Issues replacement for myself that puts the issues within the repo so that the work and the todos stay in sync. https://github.com/steviee/git-issuesAnd I bet there's numerous other projects like that.Hope you get your submarine, man! ;)
• Menu

  jordemort
  I don’t understand why any of this would take submarine money to build. GitHub itself certainly wasn’t built with submarine money.
• maerF0x0
  > 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 Feedback + commit is a loop. I often reply to comments w/ the commit sha that resolves it.
• Aeolun
  Working on it :P I’m going to take the idea to add a ‘defer’ button to PR comments. Which is fantastic.
• ifh-hn
  I'm likely wrong but this person seems to be talking about fossil-scm...
• Menu

  rhubarbtree
  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.
• BinRoo
  Great ideas, though not a huge fan of pre-commit hooks that run full CI locally :)I'd like to add another idea: automatic PR merge contingent on another PR getting merged.
• Menu

  alphabeta3r56
  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.
• elevation
  What about the ability to require signed commits so the source history can be cryptographically verified?
• tonnydourado
  Mostly agree with everything, but I will not stand for this slander against sweet potato fries!!!
• Menu

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

  wewewedxfgdf
  Doesn't sound too hard.Why don't you see how far you get in a weekend with Claude.
• NetOpWibby
  YES YES YESI agree with the author so much. Every git forge looks like Temu Github. It's boring and lame.At the top of this year I mocked up a hypothetical forge I'd use[1]. I then found the domain eol.sh was available so I snagged it. I'm currently using cgit for my personal public repos but I cannot wait to work on EOL. I'm gonna steal OP's ideas too, they sound good.---[1]: https://social.coop/@netopwibby/115918713533431249
• Menu

  keyle
  Stuff happens in the wrong order. You know the PR. Commit 1: 'Feature.' Commit 2: 'fix.' Commit 3: 'fix.' Commit 4: 'actually fix.' Commit 5: 'please.' Commit 6, made at 11:47 PM on a Thursday: 'asdfasdf'. This person has a family. This person has hobbies. This person is, at this moment, crying. You don't want the feedback loop after the commit you want it before. 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. Isn't this already totally possible? Or am I thinking subversion?
• esafak
  If anybody here does do this -- and please do -- 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.
• Menu

  shevy-java
  > I was prompted to write this after reading the good post about Ghostty leaving GitHub but it's something I've written and talked about for a few years.Many of us were annoyed already when Microslop, 'xcuse me, Microsoft assimilated GitHub. But we have to be realistic - alternatives often sucked. Sourceforge? I find creating issues there annoying to no ends. I can use gitlab, which is a bit better than sourceforge, but I also hate creating issues there. I recently saw codeberg appears to have updated its UI (I think?), but I also find it quite annoying.What GitHub got right were, initially, the UI; and also a focus on folks using github, e. g. making things easy/easier for them. They did not get everything right though - the wiki support I find awful. I rarely use the wikis because they are so bad.I think the really big problem is that there are commercial interests aka private interests. Microsoft is just one example here; it is a problem literally everywhere in similar sites. In the past I pointed at the example of discussions in issues, with regards to the xz backdoor utils - and the next day after I also participated in discussions, Microsoft took it all down; though it also does not matter if it was Microsoft or the repository owner. The problem is that individuals can too easily censor potentially useful information. The issue discussions WERE useful, and they were censored. If I remember correctly, all information from back then was never fully reinstated. Perhaps people mirrored it, but I did not see a link. The point is that I think this shows that top-down control can be really detrimental. And let's be honest: how many of you trust Microsoft? We kind of need something that is de-central, works reliably and well, and also has a good UI by default and a simple (or at the least a good) workflow. And we also need to avoid the situation where private actors can hold everyone else a hostage. I have absolutely no idea how to solve the above; perhaps it requires different approaches at the same time.The www kind of changed and I feel that private interests - aka huge mega-mega corporations in particular - made things a lot worse in the last 10-15 years here. That needs to change.
• iberator
  Just use gitlab.
• philipwhiuk
  > 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 approvedThe 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.
• Menu

  rvz
  The alternative to GitHub is already here. It is called self-hosting and there are many alternatives.The Linux kernel is not hosted on GitHub and uses cgit. Others use GitLab, or Gitea and there is also Forgejo (Which Codeberg uses) that people are using and can be self hosted.This is why now everyone is realising why "centralising everything to GitHub" [0] was a terrible idea and now GitHub has been (unsurprisingly) run into the ground.[0] https://news.ycombinator.com/item?id=22867803
• anon
  undefined
• cmrdporcupine
  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.
• jimmypk
  [dead]
• bschmidt1
  [dead]
• Menu

  bestouff
  Github, Coke and Heinz. Ewww we don't have the same taste.