Hacker News new | ask | show | jobs
by mhaberl 1097 days ago
> The only solution is to self-host. Gitea is good.

Gitea project hosts its code on GitHub: https://github.com/go-gitea/gitea. You must admit that is a bit ironic.

> age of massive ever-growing out of control tech monopolies that do whatever the fuck they want

GitHub is not the only option for source code hosting. There are alternatives like GitLab, Bitbucket, and numerous smaller ones.

8 comments

If you like the community driven fork of Gitea (which still upstreams to Gitea project) then you should check out https://forgejo.org

The fork was established at the time that Gitea got entepreneurial and founded Gitea Ltd. with plans for an enterprise version. https://codeberg.org used to run on Gitea, but switched to Forgejo, and Forgejo project is hosted on Codeberg at https://codeberg.org/forgejo

That is a real tongue-twister of a name.
Pronounced: for-jay-oh (it is a derivation of the Esperanto name for "forge")
Or maybe like .. "forge ho"
Another fork? gogs -> gitea -> forgejo lol
OSS development model functioning as intended.
It's possible with OSS development but spreading out contributors and patches over three projects instead of one with a functioning community is hardly the ideal OSS development model.
Yet, when you lose value alignment with the project, the best thing to do is to abandon the ship the sooner as possible. Insisting on total collaboration is bad for every party.
If they continue push upstream per the license then it works. There's a lot of Linux desktop apps that work this way; it's hardly a broken model.
While not an option for everyone, if you have a server with ssh access you can do:

    git init --bare /path/to/repo.git
on the server. Then locally you git clone that repo with a ssh url.

It does not have any visual MR or enterprisey features, but it works.

That's OK but too uncomfortable when managing a number of git repositories on a ssh server. I'm using gitolite [1] for that.

The features are basic and managed by editing text files and git-pushing them to a control repository: create repositories, add users and their keys, readonly or readwrite. There is no GUI but once you have a copy of the repo on your machine you can use one of the several git GUIs available for any OS.

[1] https://gitolite.com/gitolite/

What aspects of bare git repos over ssh are uncomfortable or subpar?
With gitolite I don't have to manually setup every single repo and configure access with maybe one user name per project. That would be too much. And how about read only, read write?
A large portion of people don’t want to memorise all the commands related merging, branching etc, catering towards the lowest common denominator I’d important.
How does the choice of hosting change this?

Bare repo on a server is exposed to people exactly like Github: a remote URL you put in once and forget about it.

How people use their local git repository is their business, command-line, Sourcetree, GitKraken, what have you, but any of those work with any remotes.

(Sure, git by itself does not provide the other features from the hosting services like issue tracking and pull requests, but not every workflow requires those to be linked directly to the SCM)

I don’t care for issue tracking, but I do like the usability of diffs and merging in web ui apps - my primary job is to look at code not write it (meaning I’d fail basic git merge questions) but I’ve also found out the hard way that just because I know my way around a shell doesn’t mean I can force my views on the people my company hires, and I own the company.
I use gitolite as well, it's great. Currently working on integrating it into a CI/CD pipeline, which admittedly proves to be a slight challenge, but I'm sure I'll get there eventually.
I was sold on the features but never got the hang of how to work with it.
We've been doing that for years in our org. This works perfectly.we do push open source repos to GitHub though.
I, as a Linux user, built a similar system myself by getting an FTP account, mounting it locally with curlftpfs and then using git on the mounted filesystem.
this exactly. git itself is all ya need. u can connect clients/ides like vs code to such a repo easily.
> You must admit that is a bit ironic

It's a sad situation that if you desire exposure and community building you must maintain a fork on Github, but that's how it is for smaller projects. I am in a similar situation, with some of my projects with main repos hosted on sourcehut, but most of external engagement comes from clones on github. It is what it is, and we do what we must. :)

I would agree for any other kind of project, except for a GitHub alternative.

How does it look from the potential users' perspective when the product they market is not the product they choose to use for themselves?

It looks like they are a pragmatic project that prefers to have contributors to being ideologically pure. It's not like there isn't an official repository hosted on gitea: https://gitea.com/gitea
GitLab entered a strategic partnership with Google, likely for the very same reason - feeding Google AI models with enough code.
Could you link to some of the announcements or articles. I only ask because I was totally unaware and would like to learn more.
> GitLab is working with Google Cloud because of its strong commitment to privacy and enterprise readiness, and its leadership in AI.

Google's commitment to privacy? Google's leadership in AI?

O how I love marketing, you can say just about anything

> You must admit that is a bit ironic.

Looks like they're working on migrating to a Gitea instance: https://github.com/go-gitea/gitea/issues/1029 .

Wow how pathetic that github is refusing to export their data:

https://github.com/go-gitea/gitea/issues/1029#issuecomment-1...

Failing != Refusing
Failing = Refusing + hiding behind corporate bureacracy
> You must admit that is a bit ironic.

The people are on github, so it is really enticing.

Maybe the reddit and twitter drama creates a viable enough community for federated logins to become useful.

> The people are on github, so it is really enticing.

For any other project, sure. But when building an alternative to GitHub.. there is value in dogfooding.

or just git init --bare
> You must admit that is a bit ironic.

Every time someone parrots this, I have to wonder if they did more than 5 minutes of reading - it's one of the top issues on the issue tracker and they've outright stated they will move once Gitea is at a spot where they are not losing functionality and history.

I did not parrot anything. This is the first time I have heard of Gitea, I have googled it and the 1. thing I have noticed it was hosted on GitHub. It was an original tought.

I did not care enough to open their issue tracker. I still don't. It is ironic, not a bit, a lot. That statement was a bit sarcastic.

I hope that put the end to your wondering.