Gitea VS gitlab

Same [1]. Zoom being outsourced to the implementing platform is one major pain-point. That example from us has grown in size.

We are clearly using the wrong tool for a diagram of this complexity, but the practicality of seeing commit changes in the diff, what property was changed by whom and instantly having the visual feedback in the Pull Request is just way too useful to use a "proper" tool.

[1] https://github.com/go-gitea/gitea/issues/25803

Gitea is a versatile tool for creating and managing git-based repositories, streamlining Code Review to enhance code quality for users and businesses. It integrates a CI/CD system, Gitea Actions, compatible with GitHub Actions, allowing users to create workflows in YAML or use existing plugins. Gitea's project management features include issue tasks, labeling, and kanban boards for efficient management of requirements, features, and bugs. These tools integrate with branches, tags, milestones, assignments, time tracking, and dependencies to plan and track development progress. Furthermore, Gitea supports over 20 package management types, such as Cargo, Composer, NPM, and PyPI, catering to a wide range of public or private package management needs. This comprehensive suite of features makes Gitea a powerful platform for managing development projects and packages.

Golang has a ton of single binary websites out there. The two that come to mind off hand are Gogs/Gitea only because I contributed to them

https://github.com/gogs/gogs

https://github.com/go-gitea/gitea

Reminds of the GitHub issue for hosting Gitea on Gitea, it's... a read to be sure: https://github.com/go-gitea/gitea/issues/1029

Enter Gitea - a lightweight, cost-effective, open source VCS solution suitable for small-to-medium businesses released under the MIT license:

Is anyone using Gitea or Forgejo? (the latter is a fork, I believe) They both seem like interesting/lightweight alternatives to GitHub/Gitlab.

https://about.gitea.com/

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

Gitea project hosts its code on GitHub: https://github.com/go-gitea/gitea.

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

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

(Side note: Issues are usually hash-prefixed like #1234 both on GitLab and GitHub. However, commit messages must not begin with a hash, they would be considered a comment and ignored. Therefore, GitHub has introduced the alternative prefix GH- and I've contributed a similar prefix GL- to GitLab a while ago.)

and its "oh, you want multi-arch, do you?" friend. While prosecuting this <https://gitlab.com/gitlab-org/gitlab/-/issues/339567> I learned that https://hub.docker.com/layers/multiarch/qemu-user-static/7.2... actually mutates the binfmt_misc in buildx's context in order to exec the static copy of qemu in it https://github.com/multiarch/qemu-user-static/blob/v7.2.0-1/...

and, that the buildx plugin itself has some qemu magick in it, which got addressed in a minor version bump but I couldn't track down the relevant GitHub issue this second (I've flushed it from my mind, only recalling that there were a lot of actors in that tire fire)

For folks who wanna see what led to this exploit in a Rails codebase, here’s the commit where the exploit is fixed:

https://gitlab.com/gitlab-org/gitlab/-/commit/c571840ba2f0e9...

> "RecoverableByAnyEmail"

Added 8 months ago [1]. And then one month later:

> "password_reset_any_verified_email"

Was removed. 7 months ago [2], *note* __verified__ word here.

No blaming or conspiracy intended in this post, just listing links to relevant commits.

1 - https://gitlab.com/gitlab-org/gitlab/-/commit/94069d38c9cd63...

2 - https://gitlab.com/gitlab-org/gitlab/-/commit/a935d28f3decf8...

This doesn't look like the actual fix but rather a follow-up refactor. I believe the fix is here: https://gitlab.com/gitlab-org/gitlab/-/commit/abe79e4ec43798...

    - recoverable.send_reset_password_instructions(to: email) if recoverable&.persisted?

This is actually a follow-up refactor, the fix is here: https://gitlab.com/gitlab-org/gitlab/-/commit/abe79e4ec43798...

This made me curious. Having never read the gitlab code before, and on mobile, took all of about 30 seconds to find https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/ro...

Those are some pretty clean routes!

If you want to know why GitLab decided to replace ArgoCD with Flux, you can refer to this issue: https://gitlab.com/gitlab-org/gitlab/-/issues/357947.

> ruby has just RubyMine which doesn't have a community edition and also isn't very good

I have a great deal of sympathy for RubyMine (and shudder at working for the CLion team, whew) because Ruby isn't doing the IDE author any favors. Given:

https://gitlab.com/gitlab-org/gitlab/-/blob/v16.5.0-ee/lib/g...

- what types are client_email and private_key? they are whatever type they're called with lolol

- the symbol Google::Auth::ServiceAccountCredentials just materializes; was it required in some containing context and thus is in scope by _this_ required file? are those symbols visible in every context from one of the various Gemfile lines? a hard-core rubyist knows

- where did the symbol StringIO come from? well, from require 'stringio' obviously, which is on .. err, which line exactly? I guess that lends weight to the 'this file is obviously running as a child context of some other file' theory

I think half of it is the culture of Rubyists and half of it is "productivity hacks" of "if it runs, then it must be correct"

I also recognize that I'm very clearly a static typing snob, and firmly in the camp of "please import symbols you use," but that doesn't stop me from having a great deal of sympathy for anyone who has to implement an IDE for such a monkey-patch friendly language