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.
If I could make my own GitHub
61–70 of 160 posts
Re: If I could make my own GitHub
#62I 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.
Re: If I could make my own GitHub
#63Earlier 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.
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
#64Re: If I could make my own GitHub
#65Re: If I could make my own GitHub
#66If 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.
Re: If I could make my own GitHub
#67Earlier 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.
Re: If I could make my own GitHub
#68I don’t understand why any of this would take submarine money to build. GitHub itself certainly wasn’t built with submarine money.
Re: If I could make my own GitHub
#69As 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
#70I 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?
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.