Hacker News new | ask | show | jobs
by nmcela 1094 days ago
This is huge, and unfortunately not surprising at all in the age of massive ever-growing out of control tech monopolies that do whatever the fuck they want. Whatever reads in the TOS now, they can and will just reword it when they need it. There's no trust.

Every service and utility gets enshittificated sooner or later, it's a given at the moment. I deleted all my private repos, github and all other MS services should be avoided in the future.

The only solution is to self-host. Gitea is good.

7 comments

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

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

>Whatever reads in the TOS now, they can and will just reword it when they need it. There's no trust.

This is what is crazy to me. You can agree to terms, build infrastructure around terms you agreed to, then those terms can completely change. Don't like it? Click disagree and we'll close your account, no problem!

And, thanks to politics around social media censorship, we have way too people willing to say, "Don't like the terms, don't use the platform!" to the point of normalization. Sad.

I am agreeing and adding another solution.

The other solution is political. There's a reason that governments regulate and define economic rules of the road. This is a good example of where governments need to step in. The link between generative AI and the data it is trained on needs to be carefully thought through and properly handled especially given the capitalist nature of our economy.

There is always SourceHut (https://sourcehut.org) if you want.
Do you have experience with self-hosting Guitea? I am on to fence about going with Gitea because of the recent fork of the project (Forgejo). Seems that many contributors are now contributing mainly to Forgejo.
The reason for the fork was that Gitea was going for-profit and the folks that forked to Forgejo felt they went about that transition in a way that eroded trust. Here's their explanation: https://blog.codeberg.org/codeberg-launches-forgejo.html
Gitea is itself a fork of gogs (Go Git Server)

it is functioning like Open Source should, there was a disagreement in how the project was run so it gets forked

This used to be more common place when projects were run by people not companies. I wish the practice would come back we need more forks in Free Software

It feels bad to "waste" the work that could have otherwise gone into highly-paid billable hours, or at least charity work on other repos that get more use.
I self host Gitea. Very reliable. Painless setup. I wish it had some sort of CI like github actions or bitbucket pipelines, but otherwise totally happy wit it.
> I wish it had some sort of CI like github actions or bitbucket pipeline

I use Gitea with Drone CI and it works pretty well: https://www.drone.io/

Some might also prefer the Woodpecker CI fork due to the license: https://woodpecker-ci.org/

I setup Drone as a part of my migration away from GitLab Omnibus and have no complaints so far: https://blog.kronis.dev/articles/goodbye-gitlab-hello-gitea-...

Here's the Drone example in particular: https://blog.kronis.dev/tutorials/moving-from-gitlab-ci-to-d...

It's been added recently. Not sure how they compare.
GitHub actions works in gittea at version 1.19
Just self host the community edition of gitlab. It's miles better than gitea. It's got ci pipelines, it's got a pretty robust issue tracker, it's got wiki pages, it'll integrate with ldap/ad for authentication, it's got a package repository for self hosting libraries, it's got releases, it's got a service desk to make email -> ticket pipelines, etc.
GitLab CE is far too heavy and requires minimum 4GB to run. Contains lots of componnents including PostgreSQL and Redis and various components and startup takes long. With Gitea I can run it with just 1GB or a raspberry pi. It includes wiki, package repositories and releases as well. ldap, service desk - these are enterprise features that I don't need.
> It's miles better than gitea.

Gitlab is a crazy setup full of services, with elaborate interdependence, absurd hardware requirements, iffy performance, and all the lack of confidence on security that comes from this (and it only ever running if you use their docker images and don't touch anything).

But yeah, it got everything.

Gitea has all these features as well, except maybe the last.
I've got Gitea running on a $5 Vultr instance and it's great.

Upgrades have been painless. Doesn't tax the server.

Was using Gitea when that fork happened and didn't see a reason to migrate. Looked very much like poor communication on the behalf of Gitea causing a misunderstanding.

I self host Gitea both on my home NAS and a DO droplet. I set up repos sync between the instances, it works flawlessly. I've moved the most of my projects off Github/Gitlab and overall I'm very happy with it.
I self-host gitea as a github backup just in case. It's pretty easy and well documented (it's a single executable and you can use sqlite for the database).
Cyberpunk 2077 here we come!
> The only solution is to self-host. Gitea is good.

I don’t understand your thinking and gitea’s marketing. They say in the same breath that it’s “self-hosting” and that they do “Git hosting… similar to GitHub, BitBucket, and GitLab”. — https://docs.gitea.com/

You install Gitea on a server that you own. You use that instance of Gitea to host your git repositories. That is self-hosted git hosting.

Gitea is an open source alternative to GitHub, that you run yourself.

It's a "run your own github" application. akin to Github Enterprise Server or Gitlab CE/EE, except unlike Github Enterprise Server and Gitlab EE, it's open source.
As far as I am aware, they do not offer a hosting service. I believe that statement was meant to convey that the Gitea software, once installed is a git host similar to the others. I think they were trying to differentiate between a typical remote git repo and all the web components that come with Gitea. They do offer paid support, but that's still for self hosting.