Live data from Hacker News

If I could make my own GitHub

matduggan.com

61–70 of 160 posts

Re: If I could make my own GitHub

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

Re: If I could make my own GitHub

#62

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.

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.

Re: If I could make my own GitHub

#63
post #28
post #5

Earlier quoted context omitted.

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 t…

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.

That’s super cool.

If no post planned, please consider - that’s very “an app is a home cooked meal”, and I love it.

Re: If I could make my own GitHub

#66

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.

As someone that hasn't touched Gitlab in a long time, what are some examples of their merge request guardrails?

Re: If I could make my own GitHub

#67
post #40
post #12

Earlier quoted context omitted.

Surprised to see raspberry pi for hosting data that's supposed to be integral to a workflow. I've been burned too many times by SD card corruption in the past. Do you use NVME drives nowadays, just curious.

I use RPi 4 with a cheap SSD connected via USB-to-SATA connector as a tiny home server for a year already and it works without issues. I know that not all USB-to-SATA connectors are compatible with RPi – I got lucky with the first connector I tried (Unitek). Not sure if RPi 5 has a wider compatibility.

A year isn't much. I changed I four ssds,sata,sata,nvme,nvme, about every other year, while the data store at some cheap wdc spinning rust still spins and won't stop for some years.

Re: If I could make my own GitHub

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

Re: If I could make my own GitHub

#70
post #22
post #13

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.

But why doesn't Gitea add it? It already has everything else, why are these forges always Github clones instead of doing more?

There's two reasons.

1. Gerrit's approach requires a stable Change-Id in the commits. So it doesn't just work out of box with stock git. It requires that the submitter's git configuration and the repository be set up to support this. (Note that JJ supports this out of the box)

2. Cargo cult. We have a whole generation of software developers who grew up in this generation, love GitHub, and have never known anything else. The "PR" approach is considered orthodox. Unless they went and worked at a Google or somewhere like that, they've probably never been exposed to alternative processes.

Post reply on HN