- cross-posted to:
- selfhosted@lemmy.world
- cross-posted to:
- selfhosted@lemmy.world
I’ve recently set up my own Gitea instance and I figured I’d share a simple guide on how to do it yourself. Hopefully this will be helpful to anyone looking to get started.
If you have any feedback please feel free to comment it bellow.
You must log in or # to comment.
I’ll be that guy: Use forgejo instead, its main contributor is a Non-Profit compared to Gitea’s For-Profit owners
Silly question but what is the problem with gitea being for profit?
I guess out of fear that we get another gitlab situation, where the open source offering has a load of key features eventually kept behind a paywall
At some point they will do a Redis or Terraform and say no more open source, pay us to use it.
All contributions are now owned by us and not by the person who wrote it.
As the other commenter already said it’s an abundance of caution. GItea is already moving in the direction of SaaS and an easily self-hostable solution runs counter to that plan (Gitea is already offering a managed Cloud so this is not a hypothetical). One thing that has already happened is Gitea introducing a Contributor License Agreement, effectively allowing them to change the license of the code at any time.
Thanks, I always keep forgetting what this ones called. I use a build of gitea from before it became shit but I keep telling myself I need to change to “that better one”.
If it helps, it’s supposed to be a drop-in replacement.
Same. It’s been on my list for too long.
Well I learned something new today… maybe its time to plan a migration
I think for now Forgejo is a drop-in replacement. However since they are a hard-fork, at some point in the future they will diverge enough to be mutually incompatible, so the clock is ticking on migrating.
From what I have read on the FAQ they already did a hard fork from Gitea version 1.21.11 on, which was earlier this year
https://forgejo.org/faq/#im-sold-are-migrations-from-gitea-to-forgejo-possible
There’s been a hostile takeover at Gitea and it’s now run / owned by a for-profit company. The developers forked the project under the name Forgejo and are continuing the work under a non-profit. See also: Their introduction post and a page comparing the two projects. Feel free to look up more, since I haven’t familiarized myself with the incident all that much myself. Either way though, maybe consider using Forgejo instead of Gitea.
Hostile not quite, as it was a group of core developers. But still a shitty move, especially how it was done in secrecy and disregarding other devs and the larger community.
Perhaps not a takeover so much as a betrayal, a backstabbing? Certainly hostile to the community.
That’s not what happened at all.
Forgejo is actually the one in the wrong. It’s an hostile fork that exist only because 3 devs were mad that they weren’t hired by the company created so that the core devs of Gitea could do it full time.
You’re just repeating their lies.
The Forgejo people never “owned” Gitea.
Could you please provide some sources for that? I’d like to know more.
First of all though, there is no such thing as a “hostile fork”. Being able to fork a project, for any reason, is the entire point of open source. And to be fair, not wanting to continue working for a for-profit company for free is a very good reason.
And yeah, when you suddenly turn a FOSS project that’s been developed with the help of a bunch of contributors, into a for-profit company, without making a big fuss about it beforehand and allow the contributors and community to weigh in, then yeah, that’s a hostile takeover of sorts, at least in my opinion. Developers gotta make money, but they could’ve done that by creating a new brand instead of taking over that of a previously completely FOSS project. Forgejo is preventing that exact thing from happening by joining Codeberg (a non-profit).
Try its fork forgejo instead.
But check that it has all the features you need because it lags behind gitea in some aspects (like ci).
It’s also ahead of gitea in some aspects: https://forgejo.org/faq/#is-there-a-roadmap-for-forgejo
Doesn’t matter if those features are doomed to be locked behind a paywall shortly
I started running my own Gitea instance because I wanted a private place to host my Obsidian notes.
I don’t have the time to read the article now, but permit a question: what do you use Gitea for?
I’m holding my dotfiles on a SSH server, clone/push over SSH, and it’s enough to do Git. I don’t need a ticket system, or wiki or anything (I use plaintext notes).
$ cat ~/.ssh/config Host srv Hostname srv.mywhatever.com $ git clone srv:/path/to/repo $ cd repo $ git pushGreat question
I always found setting up a git server from scratch to be quite confusing and I also like the webui that gitea offers.
But recently I have also started moving some of my github projects there so having a link (with a readme and everything) that I can share with others is important.
If you have a place to host Forgejo/Gitea, you have a place to store a Git server. Set it up like this:
$ git clone --bare myrepo myrepo.bare $ scp -r myrepo.bare srv: $ cd myrepo $ git remote add origin srv:myrepo.bare # or $ git remote set-url origin srv:myrepo.bareNow
git pushetc work similar to GitHub, but you’re using your server (namedsrvin SSH config, as shown in my previous post) as the remote storage.Selfhosted Gitea is a way to get a wiki, bug tracker or whatnot - collaborate, for example, but it’s not necessary to have a Git server for your personal use.
I’m hoping federation will allow me to get rid of my github entirely, but that’s wishful thinking I fear
I intentionally do not host my own git repos mostly because I need them to be available when my environment is having problems.
I make use of local runners for CI/CD though which is nice but git is one of the few things I need to not have to worry about.
Sidenote: If you just want a nice web frontend for others to view your Git repositories, you can use cgit instead.
I made a honest effort, but in the end went back to Git for my personal projects. The advantages Fossil has over Git (wiki, bug tracker) are trivial to emulate with versioned plaintext files, and everything about Git’s version control system just clicks with my head. Having years of experience breaking and unbreaking things helps too.
Tho one thing Fossil taught me is to merge by default, not rebase. Rebase when there’s good justification for it, and the rest of the time, have an alias for
git log --oneline --graph --first-parent(or whatever that was). --first-parent collapses a horrible branchy-mergy history into a linear overview thereof, with details available when needed.I love love love that Fossil is a single executable.
All in all, the version control wars have ended and git has won. Mercurial is another one I sort of wanna try just to see what it’s like.
Re: rebasing, I think squashing / rebasing (in place of merging) is bad but I am also one of the few people I know who tries to make a good history with good commit messages prior to opening a pull request by using interactive rebasing. (This topic is confusing to talk about because I have to say “I don’t rebase, instead o rebase” which can be confusing.)
