9 ms·

If I could make my own GitHub

135 points by matricaria 5mo ago

wewewedxfgdf 5mo ago
Doesn't sound too hard. Why don't you see how far you get in a weekend with Claude.
- nadermx 5mo ago
  I started Free.ai as a weekend project with the same mindset. And a month in the work hasn't stopped. So I second this. Just find a good name, it helps.
  - wewewedxfgdf 5mo ago
    gitwheel.com
    - wewewedxfgdf 5mo ago
      Ha ha impressively fast action. From unregistered domain to website in hours. I should have registered it myself.
      - nadermx 5mo ago
        Wasn't me; Would of been minutes not hours, and wouldn't be a coming soon. Would of been live by now, granted not in the best of shape, but live.
- kaashif 5mo ago
  This can be the mindset now with a lot of things. If you want a certain app with a feature and the app isn't open source, then you may as well just clone the app and add the feature. Claude Code and Codex (and other tools) have computer use and are perfectly capable of navigating, experimenting, cloning functionality, writing tests... If the app is open source it's probably easier to just fork and add your features though. And cheaper.
  - stavros 5mo ago
    Hell, I use the (closed-source) app Smart Audiobook Player and I wanted Audiobookshelf integration. I asked Claude, it decompiled the app, added the extra code, recompiled the APK and it works perfectly, syncing my book's progress with the server. Truly magical, it would have taken me months.
    - DANmode 5mo ago
      That’s super cool. If no post planned, please consider - that’s very “an app is a home cooked meal”, and I love it.
      - stavros 5mo ago
        I could write something, but it would be "I told Claude to do this and it did, I'm happy", there isn't really much more detail to write about. What would you like to see?
        DANmode 5mo ago
        I’ve seen a few posts just like that ^_^ It’s mostly your original story of motivation, in brief prose, that does the heavy lifting of a satisfying post, followed by exactly what spec and names of tools you used, mundane as they may feel, your exact prompt(s) (because this is of technical interest in and of itself), and screenshots of excerpts/link to output. Things that stood out to you along the way would also stand out to others. The comment alone will probably be the most intriguing one I read all day.
        stavros 5mo ago
        Huh, sure, I'll write something up today! You can subscribe to https://stavros.io https://stavros.io to get an email (there's a form under each article).
        stavros 5mo ago
        My god this took forever, legit 8 hours to write: https://www.stavros.io/posts/adding-a-feature-to-a-closed-source-app/ https://www.stavros.io/posts/adding-a-feature-to-a-closed-so... I did write a small app to do visual writing critique loops, though, because text feedback by Claude was confusing: https://github.com/skorokithakis/graphe https://github.com/skorokithakis/graphe
kortamenbra 5mo ago
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.
- dgellow 5mo ago
  One of my issue with the PR process is the way they are focused on comments first, instead of the code. You also have the same issue that email threads have, if you comment something substantial, with details you pretty much always get a response that will take one small point, and sort of ignore the rest. I also hate how noisy the discussion part is, and how GitHub handles that noise by just… hiding part of the discussion. For controversial discussion it is such a mess and horrible to track what is happening. It’s just not a great discussion platform, while also putting that as the default tab in the PR view
  - kortamenbra 5mo ago
    Yes, agreed. I tend to number my statements making it easier to track in subsequent communication just in general, this goes for emails as well.
rvz 5mo ago
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 https://news.ycombinator.com/item?id=22867803
- joshka 5mo ago
  The author's premise is that these all follow similar models to github and that's the problem they're calling out.
- xixixao 5mo ago
  If you think GitLab is a good alternative to GitHub, I have 0 trust in you. GitLab and Azure are a daily source of pain for us.
  - DarkNova6 5mo ago
    Can you name some? I keep wondering about the aversion to Gitlab. I have yet to have negative experiences with it.
    - gucci-on-fleek 5mo ago
      As a casual user, I find the UI incredibly confusing. And not just because it's different from GitHub, but because there are so many features and there are menus absolutely everywhere. I'm sure if I used it more often that I would figure it out, but it's deeply off-putting for someone who only uses it twice a year or so.
    - xixixao 5mo ago
      The really bad: UI is constantly inconsistent. You have to keep reloading the page to hope to see what’s up with your MR. Doesn’t help it’s super slow to load. The backend infra is super unreliable, with actions failing to start, merge trains being stuck, their webhooks being overloaded.
nerdypepper 5mo ago
> 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 https://blog.tangled.org/stacking , we use it a lot to build tangled itself: https://tangled.org/tangled.org/core/pulls 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 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.
- phinnaeus 5mo ago
  A remote execution cluster and CAS for build artifacts is a good way to avoid duplicate work on local vs CI, and avoid the problem of needing to trust local builds.
- Pay08 5mo ago
  Honestly, something like Radical seems a lot more seamless and complete. Or at the very least, I'm wary of Tangled's alpha tag.
  - IshKebab 5mo ago
    Also it sounds like private repos are not possible at all, which is quite the limitation! https://tangled.org/did:plc:wshs7t2adsemcrrd4snkeqli/core/issues/60 https://tangled.org/did:plc:wshs7t2adsemcrrd4snkeqli/core/is...
    - Pay08 5mo ago
      I can understand that. It's a difficult problem design-wise and needs someone that knows crypto, so I won't hold it against software that labels itself as alpha.
  - GCUMstlyHarmls 5mo ago
keyle 5mo ago
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?
- joshka 5mo ago
  yeah, you can have github actions setup on arbitrary pushes to your branches, but there's not a good interface for linking actions to bare commits, and then having conversations etc. The place where that happens is usually a PR.
- rzzzt 5mo ago
  Pre-commit hook running remotely on the forge "before they push" sounds like an oxymoron. How does the code get to the forge for feedback? That's a post-push hook!
  - Supermancho 5mo ago
    > Pre-commit hook running remotely on the forge "before they push" sounds like an oxymoron. I think the implication is that a user doesn't host the CI locally. They are suggesting that there should be? a configuration to call an API to submit the code changes for some part/total CI checking. This is only beneficial for orgs/individuals which somehow rank dev effectiveness based on how messy a branch PR history is and how many times they have submitted code that passes/fails a build. Maybe due to build cost, maybe due to ego. I understand what they are asking for, but it feels like misusing git or based on some org process rather than normal development flow. I don't understand the point.
corvad 5mo ago
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.
- stavros 5mo ago
  But why doesn't Gitea add it? It already has everything else, why are these forges always Github clones instead of doing more?
  - corvad 5mo ago
    My best guess is lack of resources and that they want to focus on the well known PR workflow instead of trying new things out of the gate. It's exactly that, it's a proven github workflow for better or for worse that most people are familiar with.
  - Aeolun 5mo ago
    Well, if you are building one you generally want to support the 99% workflow, not the experimental one. What part of gerrit is so different? Stacked PR’s work fine right (not in github, as a concept)
    - cmrdporcupine 5mo ago
      The number one thing that gerrit does that is important is keep comments tied to the code between commits. By which I mean the discussion doesn't get broken between changes, and it makes it far more trivial to iterate on things in the review without breaking the discussion. And for the reviewer to see what's changed between revisions at the specific comment point they're looking at. And then have a nice clean commit at the end instead of some dogs breakfast of merge commit with revision commits shoved in it.
      - Aeolun 5mo ago
Kwpolska 5mo ago
> 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.
- ramon156 5mo ago
  > you can just run the tests on the local machine, and you should be running them as part of your workflow. aren't you describing why you'd want a pre-commit for this? you do not have to remember to do so, and new people do not need to learn it.
  - Kwpolska 5mo ago
    There are different workflows. I sometimes commit code that does not compile, so that I have a checkpoint. Or because it’s 16:59 and I want to leave the office (and I want to protect the code I wrote from hardware failure). I’d be annoyed if any pre-commit checks took more than 2-3 minutes, and for most projects, that is not enough to build and run any meaningful tests (especially remotely).
jacobwiseberg 5mo ago
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.
- shevy-java 5mo ago
  > before Github course corrects I think the problem is that Microsoft committed to AI totally. There is no way back for them. And this also means that Github will suffer from this. Microsoft PR will tell people that AI is the solution to everything, but in reality it will lead to problems that keep on coming up again and again. Now, people may say "but Github services being down, does not have anything directly to do with AI" - while that may be true, the problem is that Microsoft shifted its strategy already, so most of its considerations will go about AI top down control. Whether people's workflow using Github is disrupted, is at best only of secondary interest to Microsoft - and that specific problem will keep on resurfacing again and again and again. Perhaps it will be silent for 3 months or so - but I am 100% certain that in the not so distant future, you'll have a new drama story about how Github is declining. This is like step-wise deterioration. Ghostty won't be the last here. Whether alternatives arise ... that will be interesting to see. I mean those alternatives need to not suck, but a lot of those websites etc... kind of suck.
  - ramon156 5mo ago
    They can support hosting your own git instance through their platform. That would imo be more interesting. You keep your code, run your runners, but don't get bombarded with bots
    - lisplist 5mo ago
      this is called GitHub Enterprise, but apparently that's mostly on life support
- colechristensen 5mo ago
  I'm building my own tools. I think people should build their own tools. The future might look something like instead of paid software or open source software what you get is a set of requirements documents for a code forge, like a recipe. You bake your own. Then you alter it to your particular use case and set of preferences.
afpx 5mo ago
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.
- pjc50 5mo ago
  Discussions like that need to get into the details: trust to do what? You don't want to let randos force push over your repository but you might want to let them submit patches.
steviee 5mo ago
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-issues https://github.com/steviee/git-issues And I bet there's numerous other projects like that. Hope you get your submarine, man! ;)
bestouff 5mo ago
Github, Coke and Heinz. Ewww we don't have the same taste.
- lstodd 5mo ago
  Guinness for the flow part, Four Roses for the review part. Forge (github or whatever) doesn't matter.
shevy-java 5mo ago
> 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.
- LinuxAmbulance 5mo ago
  The problem is running a SaaS product costs a lot of money. Mega corps can fund that, but even large numbers of devs on small budgets don't have the money to do the same. So any commercial project will inevitably trend towards supporting the interests of mega corps over the average person.
ralferoo 5mo ago
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.
- mananaysiempre 5mo ago
  There were a few efforts like that back in the day (when people still cared about offline and store-and-forward-style operation[1]), like Bugs Everywhere[3], git-appraise[4] which stored its data in Git’s little-known “notes” namespace[5], and git-bug[6] which for some reason I’ve seen mentioned quite a bit in such threads recently unlike the others—though I’m not complaining about one of them getting mentioned at least. Also, as far as read-only access, Gerrit review data is actually accessible via Git[7] (for review ABCDE, pull refs/changes/DE/ABCDE/meta instead of one of the usual numbered refs under that prefix), and someone made the effort[8] to make it accessible via Git notes too (as mentioned in the post on Git notes that I linked above). Also also, the Fossil SCM of SQLite fame somewhat famously does[9] do this kind of thing with its builtin bug tracker. It has been relegated to obscurity partly as an accident of history (Git won) and partly on the merits (it is aggressively hostile to the kind of history rewriting we are used to routinely—if not always wisely—performing in Git). Going back to working on top of Git, though, I think that part of the problem is that you really want custom merge strategies when you’re trying to build a fancy datatype, and Git’s support for them requires a lot of wrapping to make it seamless (the location tracking stuff in git-annex[10] is the only success story I am aware of, and that’s a sizeable Haskell project). The existing porcelain is just too rigid. [1] Can I have a viable replacement for PGP for that use case? Please stop telling me that I don’t exist and should screw off[2]? Please?.. [2] https://news.ycombinator.com/item?id=44239804 https://news.ycombinator.com/item?id=44239804 [3] https://github.com/aaiyer/bugseverywhere https://github.com/aaiyer/bugseverywhere [4] https://github.com/google/git-appraise https://github.com/google/git-appraise [5] https://tylercipriani.com/blog/2022/11/19/git-notes-gits-coolest-most-unloved-feature/ https://tylercipriani.com/blog/2022/11/19/git-notes-gits-coo..., https://news.ycombinator.com/item?id=44345334 https://news.ycombinator.com/item?id=44345334 (579 points, 146 comments) [6] https://github.com/git-bug/git-bug https://github.com/git-bug/git-bug [7] https://gerrit-review.googlesource.com/Documentation/note-db.html https://gerrit-review.googlesource.com/Documentation/note-db... [8] https://gerrit.googlesource.com/plugins/reviewnotes/+/refs/heads/master/src/main/resources/Documentation/refs-notes-review.md https://gerrit.googlesource.com/plugins/reviewnotes/+/refs/h... [9] https://fossil-scm.org/home/doc/trunk/www/bugtheory.wiki https://fossil-scm.org/home/doc/trunk/www/bugtheory.wiki [10] https://git-annex.branchable.com/ https://git-annex.branchable.com/
Dunedan 5mo ago
> 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/ 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/ 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.
- thayne 5mo ago
  > My approach is to utilize https://pre-commit.com/ https://pre-commit.com/ to have all checks available to run locally during commit That works fine for some things, but it doesn't work for building and testing on other platforms. For example, if I am running on linux, pre-commit won't be able to check that my changes also work on Mac and Windows.
dust-jacket 5mo ago
> 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.
- tanh 5mo ago
  This exists in Azure DevOps as Approve with Suggestions
  - jftuga 5mo ago
    I think this is a good idea as it happens anyways even in GitHub.
- ahartmetz 5mo ago
  Gerrit has -2...+2. -2: This is a bad idea, don't do that -1: This is a good idea but needs improvement +1: LGTM but I don't have enough knowledge or authority to approve +2: Approved
  - thcipriani 5mo ago
    And Gerrit has multiple review label that can be customized[0]. So you could require `Verified+2` (CI), `Code-Review+2`, and `Design+2`, for example. [0]: <https://gerrit-review.googlesource.com/Documentation/config-labels.html#label_custom https://gerrit-review.googlesource.com/Documentation/config-...>
  - chii 5mo ago
    everything except +2 is unapprove. The nuance is comments on the PR itself, rather than the state of the approval, which is binary (or ternary, if you want to count leaving it in an unknown state for extended periods of time).
philipwhiuk 5mo ago
> 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.
alphabeta3r56 5mo ago
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.
- sikozu 5mo ago
  As someone that hasn't touched Gitlab in a long time, what are some examples of their merge request guardrails?
  - alphabeta3r56 5mo ago
    https://docs.gitlab.com/user/project/merge_requests/ https://docs.gitlab.com/user/project/merge_requests/
tonnydourado 5mo ago
Mostly agree with everything, but I will not stand for this slander against sweet potato fries!!!
Aeolun 5mo ago
Working on it :P I’m going to take the idea to add a ‘defer’ button to PR comments. Which is fantastic.
serhack_ 5mo ago
I dream of a world of stagit + issue creation written in Rust. End
- Aeolun 5mo ago
  Why would issue creation written in rust be any better?
JetSetIlly 5mo ago
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.
- sikozu 5mo ago
  Can't a lot of this be accomplished by disabling features you don't need? I just checked my Forgejo instance and per repository there are options to disable: Code, Projects, Releases, Packages, Actions, Issues, PRs & Wikis.
  - JetSetIlly 5mo ago
    Yes. But I would like a public service that took care of that for me. So like github but without the bells and whistles. Part of the reason for not wanting bells and whistles is for the service to have less chance of dying under a heavy load.
    - skydhash 5mo ago
      Pretty much what sourcehut is. In addition you get a public mailing list where people can send issues and patch to.
      - JetSetIlly 5mo ago
        Oh interesting! I've heard of sourcehut of course, but never looked at it. Thanks for the pointer.
- tonymet 5mo ago
  https://sr.ht/ https://sr.ht/
- Levitating 5mo ago
masa331 5mo ago
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
gsliepen 5mo ago
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.
- cmrdporcupine 5mo ago
  So I think part of the attraction with GitHub is the integration of all 4: 1. Code review 2. Source browsing 3. Ticket tracking 4. CI It does a mediocre job at all 4. But it does a good job of integrating them all together. So I agree Gerrit is the superior code review model. but without the other 3 pieces you don't have a product. Even when I was at Google and working every day in Gerrit, I was dissatisfied with the poor integration between code search and code review and with CI. Google3/Critique/Forge/etc -- Google's internal tooling -- did a much better job of tying that all together.
jimmypk 5mo ago
[flagged]
jordemort 5mo ago
I don’t understand why any of this would take submarine money to build. GitHub itself certainly wasn’t built with submarine money.
- cmrdporcupine 5mo ago
  It doesn't need a lot of money, but it needs some absolutely gifted UX designers.
  - rirze 5mo ago
    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.
    - LinuxAmbulance 5mo ago
      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).
      - Snild 5mo ago
        Not to mention the huge amount of people who think git == github.
cmrdporcupine 5mo ago
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.
bschmidt1 5mo ago
[dead]
nirui 5mo ago
> 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.
- laxisOp 5mo ago
  A email is a notification,so how you are in the mood when it will come.can you elaborate clearly
  - atrus 5mo ago
    Close the email client. No emails, no notifications. In the mood for dealing with email, open client.
  - nirui 5mo ago
    It's simple, there's this "Star" feature on Thunderbird, so if I'm not ready to handle the mail now, I'll just click the star to mark it as important, and undo the star after I've done handling it. Or, just like what @atrus said, don't receive emails if you have other higher-priorities.
deleted 5mo ago
[deleted]
travisgriggs 5mo ago
> 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.
rererereferred 5mo ago
> 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-partial-clone-and-shallow-clone/ https://github.blog/open-source/git/get-up-to-speed-with-par...
rhubarbtree 5mo ago
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.
- esafak 5mo ago
  If you can code it up quickly please do so. I'll sign up. I'm already busy coding other things.
- rirze 5mo ago
  No one wants to do it-- but it's foundational. It's also very hard to appease everybody; from visual design to operational smoothness.
- LinuxAmbulance 5mo ago
  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.
esafak 5mo ago
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.
maerF0x0 5mo ago
> 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.
thesurlydev 5mo ago
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.
ifh-hn 5mo ago
I'm likely wrong but this person seems to be talking about fossil-scm...
mads_quist 5mo ago
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.
iberator 5mo ago
Just use gitlab.
BinRoo 5mo ago
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.
- hbogert 5mo ago
  I shouldn't have to roundtrip to a central server to validate if I'm up to par. I'm not saying the tooling is there already, but we've painted ourselves in a corner by tight coupling our ci to a centralized server.
elevation 5mo ago
What about the ability to require signed commits so the source history can be cryptographically verified?
NetOpWibby 5mo ago
YES YES YES I 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 https://social.coop/@netopwibby/115918713533431249
ajkjk 5mo ago
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.
kelvinjps 5mo ago
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

135 points by matricaria 5mo ago

wewewedxfgdf 5mo ago

Doesn't sound too hard. Why don't you see how far you get in a weekend with Claude.

nadermx 5mo ago
I started Free.ai as a weekend project with the same mindset. And a month in the work hasn't stopped. So I second this. Just find a good name, it helps.
- wewewedxfgdf 5mo ago
  gitwheel.com
  - wewewedxfgdf 5mo ago
    Ha ha impressively fast action. From unregistered domain to website in hours. I should have registered it myself.
    - nadermx 5mo ago
      Wasn't me; Would of been minutes not hours, and wouldn't be a coming soon. Would of been live by now, granted not in the best of shape, but live.
kaashif 5mo ago
This can be the mindset now with a lot of things. If you want a certain app with a feature and the app isn't open source, then you may as well just clone the app and add the feature. Claude Code and Codex (and other tools) have computer use and are perfectly capable of navigating, experimenting, cloning functionality, writing tests... If the app is open source it's probably easier to just fork and add your features though. And cheaper.
- stavros 5mo ago
  Hell, I use the (closed-source) app Smart Audiobook Player and I wanted Audiobookshelf integration. I asked Claude, it decompiled the app, added the extra code, recompiled the APK and it works perfectly, syncing my book's progress with the server. Truly magical, it would have taken me months.
  - DANmode 5mo ago
    That’s super cool. If no post planned, please consider - that’s very “an app is a home cooked meal”, and I love it.
    - stavros 5mo ago
      I could write something, but it would be "I told Claude to do this and it did, I'm happy", there isn't really much more detail to write about. What would you like to see?
      - DANmode 5mo ago
        I’ve seen a few posts just like that ^_^ It’s mostly your original story of motivation, in brief prose, that does the heavy lifting of a satisfying post, followed by exactly what spec and names of tools you used, mundane as they may feel, your exact prompt(s) (because this is of technical interest in and of itself), and screenshots of excerpts/link to output. Things that stood out to you along the way would also stand out to others. The comment alone will probably be the most intriguing one I read all day.
        stavros 5mo ago
        Huh, sure, I'll write something up today! You can subscribe to https://stavros.io https://stavros.io to get an email (there's a form under each article).
        stavros 5mo ago
        My god this took forever, legit 8 hours to write: https://www.stavros.io/posts/adding-a-feature-to-a-closed-source-app/ https://www.stavros.io/posts/adding-a-feature-to-a-closed-so... I did write a small app to do visual writing critique loops, though, because text feedback by Claude was confusing: https://github.com/skorokithakis/graphe https://github.com/skorokithakis/graphe

kortamenbra 5mo ago

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.

dgellow 5mo ago
One of my issue with the PR process is the way they are focused on comments first, instead of the code. You also have the same issue that email threads have, if you comment something substantial, with details you pretty much always get a response that will take one small point, and sort of ignore the rest. I also hate how noisy the discussion part is, and how GitHub handles that noise by just… hiding part of the discussion. For controversial discussion it is such a mess and horrible to track what is happening. It’s just not a great discussion platform, while also putting that as the default tab in the PR view
- kortamenbra 5mo ago
  Yes, agreed. I tend to number my statements making it easier to track in subsequent communication just in general, this goes for emails as well.

rvz 5mo ago

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 https://news.ycombinator.com/item?id=22867803

joshka 5mo ago
The author's premise is that these all follow similar models to github and that's the problem they're calling out.
xixixao 5mo ago
If you think GitLab is a good alternative to GitHub, I have 0 trust in you. GitLab and Azure are a daily source of pain for us.
- DarkNova6 5mo ago
  Can you name some? I keep wondering about the aversion to Gitlab. I have yet to have negative experiences with it.
  - gucci-on-fleek 5mo ago
    As a casual user, I find the UI incredibly confusing. And not just because it's different from GitHub, but because there are so many features and there are menus absolutely everywhere. I'm sure if I used it more often that I would figure it out, but it's deeply off-putting for someone who only uses it twice a year or so.
  - xixixao 5mo ago
    The really bad: UI is constantly inconsistent. You have to keep reloading the page to hope to see what’s up with your MR. Doesn’t help it’s super slow to load. The backend infra is super unreliable, with actions failing to start, merge trains being stuck, their webhooks being overloaded.

nerdypepper 5mo ago

> 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 https://blog.tangled.org/stacking , we use it a lot to build tangled itself: https://tangled.org/tangled.org/core/pulls 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 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.

phinnaeus 5mo ago
A remote execution cluster and CAS for build artifacts is a good way to avoid duplicate work on local vs CI, and avoid the problem of needing to trust local builds.
Pay08 5mo ago
Honestly, something like Radical seems a lot more seamless and complete. Or at the very least, I'm wary of Tangled's alpha tag.
- IshKebab 5mo ago
  Also it sounds like private repos are not possible at all, which is quite the limitation! https://tangled.org/did:plc:wshs7t2adsemcrrd4snkeqli/core/issues/60 https://tangled.org/did:plc:wshs7t2adsemcrrd4snkeqli/core/is...
  - Pay08 5mo ago
    I can understand that. It's a difficult problem design-wise and needs someone that knows crypto, so I won't hold it against software that labels itself as alpha.
- GCUMstlyHarmls 5mo ago

keyle 5mo ago

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?

joshka 5mo ago
yeah, you can have github actions setup on arbitrary pushes to your branches, but there's not a good interface for linking actions to bare commits, and then having conversations etc. The place where that happens is usually a PR.
rzzzt 5mo ago
Pre-commit hook running remotely on the forge "before they push" sounds like an oxymoron. How does the code get to the forge for feedback? That's a post-push hook!
- Supermancho 5mo ago
  > Pre-commit hook running remotely on the forge "before they push" sounds like an oxymoron. I think the implication is that a user doesn't host the CI locally. They are suggesting that there should be? a configuration to call an API to submit the code changes for some part/total CI checking. This is only beneficial for orgs/individuals which somehow rank dev effectiveness based on how messy a branch PR history is and how many times they have submitted code that passes/fails a build. Maybe due to build cost, maybe due to ego. I understand what they are asking for, but it feels like misusing git or based on some org process rather than normal development flow. I don't understand the point.

corvad 5mo ago

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.

stavros 5mo ago
But why doesn't Gitea add it? It already has everything else, why are these forges always Github clones instead of doing more?
- corvad 5mo ago
  My best guess is lack of resources and that they want to focus on the well known PR workflow instead of trying new things out of the gate. It's exactly that, it's a proven github workflow for better or for worse that most people are familiar with.
- Aeolun 5mo ago
  Well, if you are building one you generally want to support the 99% workflow, not the experimental one. What part of gerrit is so different? Stacked PR’s work fine right (not in github, as a concept)
  - cmrdporcupine 5mo ago
    The number one thing that gerrit does that is important is keep comments tied to the code between commits. By which I mean the discussion doesn't get broken between changes, and it makes it far more trivial to iterate on things in the review without breaking the discussion. And for the reviewer to see what's changed between revisions at the specific comment point they're looking at. And then have a nice clean commit at the end instead of some dogs breakfast of merge commit with revision commits shoved in it.
    - Aeolun 5mo ago

Kwpolska 5mo ago

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

ramon156 5mo ago
> you can just run the tests on the local machine, and you should be running them as part of your workflow. aren't you describing why you'd want a pre-commit for this? you do not have to remember to do so, and new people do not need to learn it.
- Kwpolska 5mo ago
  There are different workflows. I sometimes commit code that does not compile, so that I have a checkpoint. Or because it’s 16:59 and I want to leave the office (and I want to protect the code I wrote from hardware failure). I’d be annoyed if any pre-commit checks took more than 2-3 minutes, and for most projects, that is not enough to build and run any meaningful tests (especially remotely).

jacobwiseberg 5mo ago

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.

shevy-java 5mo ago
> before Github course corrects I think the problem is that Microsoft committed to AI totally. There is no way back for them. And this also means that Github will suffer from this. Microsoft PR will tell people that AI is the solution to everything, but in reality it will lead to problems that keep on coming up again and again. Now, people may say "but Github services being down, does not have anything directly to do with AI" - while that may be true, the problem is that Microsoft shifted its strategy already, so most of its considerations will go about AI top down control. Whether people's workflow using Github is disrupted, is at best only of secondary interest to Microsoft - and that specific problem will keep on resurfacing again and again and again. Perhaps it will be silent for 3 months or so - but I am 100% certain that in the not so distant future, you'll have a new drama story about how Github is declining. This is like step-wise deterioration. Ghostty won't be the last here. Whether alternatives arise ... that will be interesting to see. I mean those alternatives need to not suck, but a lot of those websites etc... kind of suck.
- ramon156 5mo ago
  They can support hosting your own git instance through their platform. That would imo be more interesting. You keep your code, run your runners, but don't get bombarded with bots
  - lisplist 5mo ago
    this is called GitHub Enterprise, but apparently that's mostly on life support
colechristensen 5mo ago
I'm building my own tools. I think people should build their own tools. The future might look something like instead of paid software or open source software what you get is a set of requirements documents for a code forge, like a recipe. You bake your own. Then you alter it to your particular use case and set of preferences.

afpx 5mo ago

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.

pjc50 5mo ago
Discussions like that need to get into the details: trust to do what? You don't want to let randos force push over your repository but you might want to let them submit patches.

steviee 5mo ago

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-issues https://github.com/steviee/git-issues And I bet there's numerous other projects like that. Hope you get your submarine, man! ;)

bestouff 5mo ago

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

lstodd 5mo ago
Guinness for the flow part, Four Roses for the review part. Forge (github or whatever) doesn't matter.

shevy-java 5mo ago

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

LinuxAmbulance 5mo ago
The problem is running a SaaS product costs a lot of money. Mega corps can fund that, but even large numbers of devs on small budgets don't have the money to do the same. So any commercial project will inevitably trend towards supporting the interests of mega corps over the average person.

ralferoo 5mo ago

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.

mananaysiempre 5mo ago
There were a few efforts like that back in the day (when people still cared about offline and store-and-forward-style operation[1]), like Bugs Everywhere[3], git-appraise[4] which stored its data in Git’s little-known “notes” namespace[5], and git-bug[6] which for some reason I’ve seen mentioned quite a bit in such threads recently unlike the others—though I’m not complaining about one of them getting mentioned at least. Also, as far as read-only access, Gerrit review data is actually accessible via Git[7] (for review ABCDE, pull refs/changes/DE/ABCDE/meta instead of one of the usual numbered refs under that prefix), and someone made the effort[8] to make it accessible via Git notes too (as mentioned in the post on Git notes that I linked above). Also also, the Fossil SCM of SQLite fame somewhat famously does[9] do this kind of thing with its builtin bug tracker. It has been relegated to obscurity partly as an accident of history (Git won) and partly on the merits (it is aggressively hostile to the kind of history rewriting we are used to routinely—if not always wisely—performing in Git). Going back to working on top of Git, though, I think that part of the problem is that you really want custom merge strategies when you’re trying to build a fancy datatype, and Git’s support for them requires a lot of wrapping to make it seamless (the location tracking stuff in git-annex[10] is the only success story I am aware of, and that’s a sizeable Haskell project). The existing porcelain is just too rigid. [1] Can I have a viable replacement for PGP for that use case? Please stop telling me that I don’t exist and should screw off[2]? Please?.. [2] https://news.ycombinator.com/item?id=44239804 https://news.ycombinator.com/item?id=44239804 [3] https://github.com/aaiyer/bugseverywhere https://github.com/aaiyer/bugseverywhere [4] https://github.com/google/git-appraise https://github.com/google/git-appraise [5] https://tylercipriani.com/blog/2022/11/19/git-notes-gits-coolest-most-unloved-feature/ https://tylercipriani.com/blog/2022/11/19/git-notes-gits-coo..., https://news.ycombinator.com/item?id=44345334 https://news.ycombinator.com/item?id=44345334 (579 points, 146 comments) [6] https://github.com/git-bug/git-bug https://github.com/git-bug/git-bug [7] https://gerrit-review.googlesource.com/Documentation/note-db.html https://gerrit-review.googlesource.com/Documentation/note-db... [8] https://gerrit.googlesource.com/plugins/reviewnotes/+/refs/heads/master/src/main/resources/Documentation/refs-notes-review.md https://gerrit.googlesource.com/plugins/reviewnotes/+/refs/h... [9] https://fossil-scm.org/home/doc/trunk/www/bugtheory.wiki https://fossil-scm.org/home/doc/trunk/www/bugtheory.wiki [10] https://git-annex.branchable.com/ https://git-annex.branchable.com/

Dunedan 5mo ago

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

thayne 5mo ago
> My approach is to utilize https://pre-commit.com/ https://pre-commit.com/ to have all checks available to run locally during commit That works fine for some things, but it doesn't work for building and testing on other platforms. For example, if I am running on linux, pre-commit won't be able to check that my changes also work on Mac and Windows.

dust-jacket 5mo ago

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

tanh 5mo ago
This exists in Azure DevOps as Approve with Suggestions
- jftuga 5mo ago
  I think this is a good idea as it happens anyways even in GitHub.
ahartmetz 5mo ago
Gerrit has -2...+2. -2: This is a bad idea, don't do that -1: This is a good idea but needs improvement +1: LGTM but I don't have enough knowledge or authority to approve +2: Approved
- thcipriani 5mo ago
  And Gerrit has multiple review label that can be customized[0]. So you could require `Verified+2` (CI), `Code-Review+2`, and `Design+2`, for example. [0]: <https://gerrit-review.googlesource.com/Documentation/config-labels.html#label_custom https://gerrit-review.googlesource.com/Documentation/config-...>
- chii 5mo ago
  everything except +2 is unapprove. The nuance is comments on the PR itself, rather than the state of the approval, which is binary (or ternary, if you want to count leaving it in an unknown state for extended periods of time).

philipwhiuk 5mo ago

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

alphabeta3r56 5mo ago

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.

sikozu 5mo ago
As someone that hasn't touched Gitlab in a long time, what are some examples of their merge request guardrails?
- alphabeta3r56 5mo ago
  https://docs.gitlab.com/user/project/merge_requests/ https://docs.gitlab.com/user/project/merge_requests/

tonnydourado 5mo ago

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

Aeolun 5mo ago

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

serhack_ 5mo ago

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

Aeolun 5mo ago
Why would issue creation written in rust be any better?

JetSetIlly 5mo ago

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.

sikozu 5mo ago
Can't a lot of this be accomplished by disabling features you don't need? I just checked my Forgejo instance and per repository there are options to disable: Code, Projects, Releases, Packages, Actions, Issues, PRs & Wikis.
- JetSetIlly 5mo ago
  Yes. But I would like a public service that took care of that for me. So like github but without the bells and whistles. Part of the reason for not wanting bells and whistles is for the service to have less chance of dying under a heavy load.
  - skydhash 5mo ago
    Pretty much what sourcehut is. In addition you get a public mailing list where people can send issues and patch to.
    - JetSetIlly 5mo ago
      Oh interesting! I've heard of sourcehut of course, but never looked at it. Thanks for the pointer.
tonymet 5mo ago
https://sr.ht/ https://sr.ht/
Levitating 5mo ago

masa331 5mo ago

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

gsliepen 5mo ago

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.

cmrdporcupine 5mo ago
So I think part of the attraction with GitHub is the integration of all 4: 1. Code review 2. Source browsing 3. Ticket tracking 4. CI It does a mediocre job at all 4. But it does a good job of integrating them all together. So I agree Gerrit is the superior code review model. but without the other 3 pieces you don't have a product. Even when I was at Google and working every day in Gerrit, I was dissatisfied with the poor integration between code search and code review and with CI. Google3/Critique/Forge/etc -- Google's internal tooling -- did a much better job of tying that all together.

jimmypk 5mo ago

[flagged]

jordemort 5mo ago

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

cmrdporcupine 5mo ago
It doesn't need a lot of money, but it needs some absolutely gifted UX designers.
- rirze 5mo ago
  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.
  - LinuxAmbulance 5mo ago
    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).
    - Snild 5mo ago
      Not to mention the huge amount of people who think git == github.

cmrdporcupine 5mo ago

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.

bschmidt1 5mo ago

[dead]

nirui 5mo ago

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

laxisOp 5mo ago
A email is a notification,so how you are in the mood when it will come.can you elaborate clearly
- atrus 5mo ago
  Close the email client. No emails, no notifications. In the mood for dealing with email, open client.
- nirui 5mo ago
  It's simple, there's this "Star" feature on Thunderbird, so if I'm not ready to handle the mail now, I'll just click the star to mark it as important, and undo the star after I've done handling it. Or, just like what @atrus said, don't receive emails if you have other higher-priorities.

deleted 5mo ago

[deleted]

travisgriggs 5mo ago

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

rererereferred 5mo ago

> 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-partial-clone-and-shallow-clone/ https://github.blog/open-source/git/get-up-to-speed-with-par...

rhubarbtree 5mo ago

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.

esafak 5mo ago
If you can code it up quickly please do so. I'll sign up. I'm already busy coding other things.
rirze 5mo ago
No one wants to do it-- but it's foundational. It's also very hard to appease everybody; from visual design to operational smoothness.
LinuxAmbulance 5mo ago
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.

esafak 5mo ago

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.

maerF0x0 5mo ago

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

thesurlydev 5mo ago

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.

ifh-hn 5mo ago

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

mads_quist 5mo ago

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.

iberator 5mo ago

Just use gitlab.

BinRoo 5mo ago

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.

hbogert 5mo ago
I shouldn't have to roundtrip to a central server to validate if I'm up to par. I'm not saying the tooling is there already, but we've painted ourselves in a corner by tight coupling our ci to a centralized server.

elevation 5mo ago

What about the ability to require signed commits so the source history can be cryptographically verified?

NetOpWibby 5mo ago

YES YES YES I 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 https://social.coop/@netopwibby/115918713533431249

ajkjk 5mo ago

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.

kelvinjps 5mo ago

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