For the past few days I've been playing with Forgejo (from the Codeberg people). It is fantastic.

The biggest difference is memory usage. GitLab is Ruby on Rails and over a dozen services (gitlab itself, then nginx, postgrest, prometheus, etc). Forgejo is written in go and is a single binary.

I have been running GitLab for several years (for my own personal use only!) and it regularly slowly starts to use up the entirety of the RAM on a 16GB VM. I have only been playing with Forgejo for a few days, but I am using only 300MB of the 8 GB of RAM I allocated, and that machine is running both the server and a runner (it is idle but...).

I'm really excited about Forgejo and dumping GitLab. The biggest difference I can see if that Forgejo does not have GraphQL support, but the REST API seems, at first glance, to be fine.

EDIT: I don't really understand the difference between gitea and forgejo. Can anyone explain? I see lots of directories inside the forgejo volume when I run using podman that clearly indicate they are the same under the hood in many ways.

EDIT 2: Looks like forgejo is a soft fork in 2022 when there were some weird things that happened to governance of the gitea project: https://forgejo.org/compare-to-gitea/#why-was-forgejo-create...

The hacker spirit alive and well.

I agree with the sentiment, but want to point out that email can be used to turn push into pull, by auto-filtering the respective email notifications into a separate dedicated email folder, which you can choose to only look at when you want.

Someone kind enough to explain this to me? What's the difference between push model and pull model? What about push model makes it difficult to work offline?

And the github frontend developers are aware of these accessibility problems (via the forums and bug reports). They just don't care anymore. They just want to make the site appear to work at first glance which is why index pages are actual text in html but nothing else is.

The best reason right here.

1. Oh! It's "d.i.l.l.o."! I misread that as something else.

2. After reading many comments in this thread, I must admit I am stupefied at the sheer amount of stuff that can go into merely setting up and maintaining a version control system for a project.

3. I have cited every one of the same problems OP enumerates as my argument for switching new projects over to self-hosted fossil. It also helps a good bit with #2 above when you're a small organization and you're the sole software engineer, sysadmin, and tier >1 support. It's a much simpler VCS that's closer to using perforce in my experience. YMMV, but it's the kind of VCS that doesn't qualify as a skill on a resume.

4. I also find GH deploy keys frustrating because I can't use the same key for multiple repositories. I have 3 separate applications that each run on 4 machines in my cluster, and I have to configure 12 separate deploy keys on GitHub and in my ~/.ssh/config file.

I love this. I used to be a big fan of linear (because the alternatives were dog water), but this also opened the question "why even have a seperate, disconnected tool?"

Most of my personal projects have a TODO.md somewhere with a list of things i need to work on. If people really need a frontend for bugs, it wouldn't be more than just rendering that markdown on the web.

I went to gitlab from github due to Microsoft changes, my needs are very simple so far gitlab seems OK.

I also mirror just the current source on sdf.org via gopher. If gitlab causes issues this could very well become my main site.

https://wkoszek.github.io/easyforgejo/

> the [GitHub] frontend barely works without JavaScript, so we cannot open issues, pull requests, source code or CI logs in Dillo itself, despite them being mostly plain HTML

because Dillo is a simple browser without a JS engine. And that is a perfectly valid reason to leave GitHub.

This is a huge with github and I would desperately want a github where issues are visible, but the ability to create or modify them is STRICTLY locked down to project members, and non members can only post Discussions for problems. I really prefer that I write the issue(s) based an "intake discussion" so to speak.

Another social issue on GitHub: you cannot use the "good first issue" tag on a public repository without being subjected to low quality drive-by PRs or AI slop automatically submitted by someone's bot.

I think the issue with centralization is still understated. I know developers who seem to struggle reading code if it's not presented by VS Code or a GitHub page. And then, why not totally capture everyone into developing just with GitHub Codespaces?

This is exactly what well-intentioned folk like to see: it's solving everyone's problems! Batteries included, nothing else is needed! Why use your own machine or software that doesn't ping into a telemetry hell-hole of data collection on a regular basis?

I'm not part of the project at all, but this is the only offline code review system I've found.

As for gitlab versus github: I understand that gitlab may have more features and thus options, but I can't stand its default UI. Every time I use it I am annoyed compared to the github variant. Perhaps gitlab is nicer to have for teams, but from a user's perspective, I feel gitlab is worse than github (UI-wise primarily).

The post does not mention CI anywhere else, are they doing anything with it, keeping it on GitHub, or getting rid of it?

> Furthermore, the web frontend doesn't require JS, so I can use it from Dillo (I modified cgit CSS slightly to work well on Dillo).

That sounds like a bad approach to developing a Web browser, surely it would be better to make Dillo correctly work with the default cgit CSS (which is used by countless projects)?

Sourcehut is hosted in The Netherlands, and Codeberg in Germany.

Not only did they spend years rewriting the frontend from Pjax to I think React? They also manage to lost customer because of it.

Note that for some of the web pages on GitHub, the data is included as JSON data within the HTML file, although this schema is undocumented and sometimes changes. User scripts (which you might have to maintain due to these changes) can be used to display the data without any additional downloads from the server, and they can be much shorter and faster than GitHub's proprietary scripts.

Using a GPG key to sign the web page and releases is helpful (for the reasons they explain there), although there are some other things that might additionally help (if the conspiracy was not making it difficult to do these things with X.509 certificates in many ways).

Besides the usability problems with bloated MS Shitware, this is a strategic point that I see considered far too rarely for my taste.

I mean, are the scripts writing themselves here, boys?