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.

  • Neshura
    link
    fedilink
    English
    153
    edit-2
    4 months ago

    I’ll be that guy: Use forgejo instead, its main contributor is a Non-Profit compared to Gitea’s For-Profit owners

      • @[email protected]
        link
        fedilink
        English
        644 months ago

        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

      • slazer2au
        link
        fedilink
        English
        394 months ago

        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.

      • Neshura
        link
        fedilink
        English
        194 months ago

        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.

    • @PenisDuckCuck9001
      link
      English
      9
      edit-2
      4 months ago

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

  • copygirl
    link
    fedilink
    English
    1384 months ago

    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.

    • poVoq
      link
      fedilink
      English
      33
      edit-2
      4 months ago

      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.

      • @[email protected]
        link
        fedilink
        English
        10
        edit-2
        4 months ago

        Perhaps not a takeover so much as a betrayal, a backstabbing? Certainly hostile to the community.

    • @[email protected]
      link
      fedilink
      English
      34 months ago

      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.

      • copygirl
        link
        fedilink
        English
        4
        edit-2
        4 months ago

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

  • @[email protected]
    link
    fedilink
    English
    114 months ago

    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 push
    
    • @[email protected]OP
      link
      fedilink
      English
      24 months ago

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

      • @[email protected]
        link
        fedilink
        English
        44 months ago

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

        Now git push etc work similar to GitHub, but you’re using your server (named srv in 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.

        • @[email protected]
          link
          fedilink
          English
          5
          edit-2
          4 months ago

          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.

          No, but it is amazing for browsing your repos and visually seeing what you did in a past commit or a branch, while your IDE is open to your latest code. Or copying and pasting something that you need from a different repo.

          For Git experts, sure they can probably do all that better inside their IDE or CLI, but for us plebs, having your own Forgejo is incredible 😍

          I have mine configured to disable the wiki and issues, etc, it’s just the repo browser.

    • @[email protected]
      link
      fedilink
      English
      14 months ago

      I’m hoping federation will allow me to get rid of my github entirely, but that’s wishful thinking I fear

  • @[email protected]
    link
    fedilink
    English
    64 months ago

    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.

  • @[email protected]
    link
    fedilink
    English
    54 months ago

    Sidenote: If you just want a nice web frontend for others to view your Git repositories, you can use cgit instead.

      • JackbyDev
        link
        fedilink
        English
        24 months ago

        After dealing with tcl errors trying to test sqlite, I feel I’ve never seen a more scathing criticism of fossil.

    • @[email protected]
      link
      fedilink
      English
      13 months ago

      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.

      • JackbyDev
        link
        fedilink
        English
        13 months ago

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