Hacker News Reader

Gitea is prob the best pick if you fancy a github-a-like. Hopefully we soon have forgefed/AP federation, to facilitate collaboration across servers. The intention is to make it a standard protocol for forges to share not just code but also the coordination/social parts, so a server can choose to allow outside contribution without registering or e-mail.

As soon as you get a Postgres server up and have some flow to keep your infra in source control (ansible+docker-compose/systemd goes a long way; they're a sane starting point for the unopionated mostly because of popularity), setting up new services is pretty straight-forward.

I did use nexus at work but tbh the official docker-registry container and a static webserver have proven sufficient for personal use.

Here's a decent run-down of alternatives for hosting a forge, it all comes down to preference: https://www.paritybit.ca/blog/choosing-a-self-hosted-git-ser...

> Or is the only viable advice nowadays: "Don't. Just use the cloud."?

For the people who really can't or won't self-host, I'd suggest at least looking at smaller providers rather than defaulting to big tech for everything.

Gitea + Nexus + Drone CI is what I've been using for a while and I really like it. I dumped GitLab after it became obvious they have no interest in serving the low end (ie: small users). I have no regrets. Gitea is a much better fit for me.

Maybe I'm bias because I've become accustomed to Gitea, but I really feel like Gitea augments my workflow while GitLab and GitHub are trying to usurp my workflow. I use GitHub, but only for push mirroring when I want to use something like Cloudflare Pages / Functions that do GitOps style managed deployment.

As for an extra layer of auth, I think Cloudflare Access makes a lot of sense for small users. Put everything behind Cloudflare, use split horizon DNS for LAN access, and rely on Cloudflare to pre-auth all users before they can connect via the internet.

It's surprisingly easy and efficient to run a Gitea instance behind a reverse proxy (Nginx et. al) plugged into Let's Encrypt. The built in sqlite3 DB method is plenty capable and snappy for a dozen projects and small team of people, it runs comfortably on the typical $5 cloud server and it offers a lot of capabilities (to the users and the Admin). Hobbyist groups like Disroot and non-profits like Codeberg are using it with much success, many folks find it easy to run their own personal instance within a few hours. Plenty of people share their build recipes online to just "clone and go" to DIY.

Second Gitea. Easy to deploy and maintain. Good enough for many people with intuitive interface.

For a small team, you could look at fossil: https://fossil-scm.org. It’s what SQLite team uses.

Oh hey, i think there was a post about Fossil here on HN a few days ago: https://news.ycombinator.com/item?id=30815693

It is most certainly a nice project and i'm all for alternatives to Git, but for many people having to give up their current tooling (e.g. IDE integrations, specific tools for graphical graphs, interactive staging of chunks, rebasing etc.) would probably be a non starter, since it's another source control system entirely, instead of a front-end/enhancement of what Git provides (e.g. ticketing, wikis, merge/pull request discussions, CI etc.).

Here's hoping that Fossil has a nice future ahead of it, there is certainly a number of projects that would benefit from it's relative simplicity when compared to Git!

Also their docs are pretty simple to understand: https://fossil-scm.org/home/doc/trunk/www/permutedindex.html

Though personally i really liked the more visual nature of SourceHut's page: https://sourcehut.org/

The IDE integrations bit is the most difficult thing for me; there was a fossil plugin for Jetbrains IDEs/IntelliJ, but it stopped being maintained, I maintained it a bit, but a large breaking change meant I didn't have enough time to keep it up, so I had to migrate away. I love fossil, but some things are difficult without a community around it developing the tools for it.

There is a VS Code extension that integrates fossil, and it works almost identically to the git integration, for the most part.

You can actually mirror a fossil repository to Git and use any of Git's downstream capabilities.

https://fossil-scm.org/home/doc/trunk/www/mirrortogithub.md

There was some muttering on the fossil site somewhere about supporting git format. Darcs was another thing like that, which was superior to git in most ways I can think of, while fossil has an anti-rebasing ideology that makes it unacceptable for certain types of git workflow. I don't know how that can be resolved while switching to git format. I do like integrating issue tracking with source control.

Unfortunately darcs suffered from the patch-of-doom problem, where if you were unlucky an exponentiation merge would kill all performance of your repository.

The darcs FAQ from 2012 reports it as still unfixed:

http://darcs.net/FAQ/Performance#is-the-exponential-merge-pr...

(Yes this was real, and yes we hit it. I liked the patch-centric darcs approach, but that was enough to make us migration to mercurial, then later git.)

The Tcl dev team uses it as well. They seem to like it.

Have you used it?

It's not for the general mass to say the least. You're better off using other focused products for each components than something that does everything in average ways.

The visual looks like they combined components from 20 years ago.

I use it every day for personal projects. Since I’ve been writing code for more than 20 years, the aesthetics aren’t as relevant to me. It’s a useful tool that works quite well. It’s not trying to win this year’s design competition.

I really like that Gitea is operationally simple and can run on a potato. If your team's fairly small, you can use SQLite to make it even simpler. GitLab's way, way too heavy.

By far the easiest method, if you mostly trust your friends, is to forego the web UI and just use a directory on an SSH server. Do `mkdir project.git && cd project.git && git init --bare` and throw everybody's SSH keys into authorized_keys on the server, `git remote add origin user@server:project.git` on the client. The problems with this are that there's no privilege separation, i.e. everyone can do anything, there's no audit logs, and as mentioned previously there's no web UI. If everyone is actually expected to have a local copy of the repository, though, I don't see this as a huge issue. Issue tracking can be handled by a TODO file in the same or a separate repository.

When going this way, I can also recommend gitolite. It solves the whole privilege thing.

I find self-hosting GitLab reasonably enjoyable. I use the Docker image (which contains the omnibus installation). It takes a ridiculous time to boot but I can only remember one time when upgrading wasn't as simple as pulling the new version and re-creating the container. Don't remember what went wrong though.

It's login-only, there's no other users, so I'm not too worried about security.

For anything public I use GitHub.

I've had several upgrade issues. Once several configuration settings were deprecated then removed... Silently. It was difficult to discover why it would no longer start. Another time a bunch of repositories only partially migrated, and appeared empty on clone.

Mostly it's the frequency of updates that's a pain, there are enough critical vulnerabilities that you have to stay on top of it.

I am the dog lying on a nail and occasionally whimpering at the moment though.

GitLab is a prime example of "do many things and do them averagely". Sure it got many features but there are bugs and each feature isn't as polished as other isolated apps and it takes huge resource.

How it turned out to be a unicorn, I guess good sales and not by the technical advantage.

if you do self host, then please think about backups, especially for the stuff not in the repo (issues, wiki, whatever else)