eikenberry an hour ago

    Code discussion anywhere anytime
    
    Select any code or diff to start discussion. Suggest and apply changes. Discussions stay with code to help code understanding.
How do the discussions stay with the code? Git notes?
goofiw 2 hours ago

This looks super cool - especially given the changes to github’s leadership.

One minor note - on mobile safari there didn’t seem to be any state update on press of buttons, and submission was not clear until the backend server seemed to respond. My internet connection is a little slow and it was unclear tapping the button worked. I would expect a little loading state or at least ui to show the button as disabled during submission.

Havoc an hour ago

I recall looking at it maybe 2-3 years ago and deciding against it. And it never seemed to get traction in the selfhosted community either.

...but I can't for the life of me recall why. Definitely wasn't a radioactive red flag issue...but some aspect around CI wasn't for me.

In general though with things like this that carry an open license and have a docker image you're better off trying it yourself than listening to randoms like me

  • s09dfhks an hour ago

    This is why I dropped it. The CI/CD configurations were some weird proprietary format where as gitlab/gitea/forejo are all (mostly) feature compliant with my already existing github workflow files

    • elevation an hour ago

      I evaluated moving from Gitea to OneDev before Gitea had CI. OneDev was useable, I didn't mind it, but I don't run java anywhere else so I decided against adopting it. A few years later and now Gitea/Forgejo are at feature parity.

hk1337 an hour ago

Ooh! My interest is peaked seeing it is written in Java.

kachapopopow an hour ago

Seems like heavier version of gitea with a pricing section.

aime4money 2 hours ago

Fossil is that you?

  • fair_enough an hour ago

    Fossil started as "not invented here", but it has grown into something I like a lot more than Git. Knowing how to use a version control system should be an incidental skill (akin to simple shell commands like "cp" and "ln"), not something that needs to be mentioned in a job posting's role description.

    I also appreciate that the default workflow for undoing bad merges is a whiteout rather than a true "delete".

    To each his own, but having worked with CVS, SVN, Perforce, Git, and Fossil, the centralized model is much less work for release engineering and administration most of the time. If I were a maintainer of the Linux kernel of one of the many Linux distros where you have potentially thousands of contributors to one codebase, I would use git because it scales up better.

    However, I wouldn't underestimate the value of scaling down well, especially for all the people around here building some startup out of a barndominium. A VCS that includes its own GUI-based admin tool and is simple enough to used by some high school intro to web design class is a good thing in my book.

odie5533 an hour ago

Why do people self-host things like this instead of Github or Gitlab? I don't want to maintain more services for my services. Who has time for that.

  • homebrewer an hour ago

    Our gitea instance had roughly five minutes of downtime in total over the past year, just to upgrade gitea itself. All in the middle of the night. How much downtime has GitHub seen over the same period, and how many people's work was affected by that?

  • pheggs 36 minutes ago

    I've been hosting a git service for quite a while now and it's maybe around half an hour per year of maintenance work. It's totally worth it in my opinion, it's so much better on almost every way ... One big reason is decentralization. Full control of data, change what you want, then things like the current npmjs attack show the downsides of having everyone using the same thing, and so much more

    • odie5533 19 minutes ago

      Backups, OS upgrades, version upgrades, firewall management, DDoS management. I just find self-hosting to be excessive to do right.

      • chasd00 a few seconds ago

        tinkering with services and networks and the whole self-hosting concept is pretty fun for many people.

  • elevation an hour ago

    One answer might be to avoid LLMs training off the intellectual property that your humans typed out for you. But as LLM code generation tools take off, it's a losing battle for most orgs to prevent staff from using LLMs to generate the code in the first place, so this particular advantage is being subverted.

    • odie5533 18 minutes ago

      This probably only matters for 1-2 years tops. LLMs are taking off pretty fast.

  • d12bb an hour ago

    Especially as self-hosting means loosing the community aspect of GitHub. Every potential contributor already has an account. Every new team member already knows how to use it.

    • nirvdrum an hour ago

      You’re assuming people are self-hosting open source projects on their gut servers. That’s often not the case. Even if it were, GitHub irked a lot of people using their code to train Copilot.

      I self-host gitea. It took maybe 5 minutes to set up on TrueNAS and even that was only because I wanted to set up different datasets so I could snapshot independently. I love it. I have privacy. Integrating into a backup strategy is quite easy —- it goes along with the rest of my off-site NAS backup without me needing to retain local clones on my desktop. And my CI runners are substantially faster than what I get through GitHub Actions.

      The complexity and maintenance burden of self-hosting is way overblown. The benefits are often understated and the deficiencies of whatever hosted service left unaddressed.

  • kachapopopow an hour ago

    because: 1) privacy - don't want projects leaving a closed circle of people 2) compliance - you have to self-host and gitlab/github are way too expensive for what they provide when open-source alternatives exist 3) you just want to say fuck you to coorperate (nothing is free) and join the clippy movement.

  • hamdingers an hour ago

    As a mirror of my GitHub repositories following the 3-2-1 backup principle.