Thanks, this was very helpful! I was scanning the prose on the Codeberg website looking to see if Codeberg itself was open source, but all it said was that it was "free" and "non-profit."

Now I see that Gitea is the software (basically a clone of GitHub that is visually almost div-for-div, released with an MIT license, that you can host yourself), and Codeberg is central hosting (a "hub") running Gitea, operated as a non-profit.

Gitea is a fork of gogs.

Gogs is still in development as well. If people are interested, definitely check that out as well.

If you don’t need issue tracking then also check out cgit.

Gitea is very slow (eg 4s GET requests) for large codebases. cgit is like lightning.

I had developed the impression that gitea kept all the project metadata -- bug tracking, PRs, etc -- in the same repository with the project code. Was this impression correct? Looking at the "Comparison" page does not suggest anything, one way or the other.

To me that would be the most important differentiator. Do any of the others do it?

Wait, is that something you would want? I would find it pretty awful if my git history for my code had all the other things like issues and PR metadata in it. Could potentially see it being useful if it were stored in an "auxiliary" repo that I could pull separately.

The big advantage would be that all that metadata would also be decentralised, i.e. I'd have a backup of all that on my own PC, and I could push it to a different host to automatically transfer everything, whereas e.g. GitLab has had to write custom import scripts for GitHub metadata, and you just have to hope that everything maps cleanly if you use it.

Of course I want it. History is history. Furthermore, why should PRs, bug reports, and build artifacts not be able to refer directly to source objects and revisions, and vice versa?

A simple way to represent it might be as an ASCII dump of one or more databases representing it all, so you could roll back to any day's state; or as an update-log transcript, so you could roll back to the state after any given transaction. Both amount to successive diffs, so are reasonably compact.

> History is history

Except PRs, bug reports etc. can't affect the runtime behavior of your program, only code can. There are many times when I am looking through a dependency's history to see "what changed?" in order to decide if I want to pull a new version, and the ONLY thing I want to look at in that case are code changes.

> Furthermore, why should PRs, bug reports, and build artifacts not be able to refer directly to source objects and revisions, and vice versa?

I do that all the time in GitHub today.

I certainly understand wanting that auxiliary data to be versioned, and I also understand wanting it to be in a portable, distributed format like Git. I just definitely don't want it cluttering up the history of my code

Also, security is a big deal. I often want to allow pretty much anyone to open a PR or an issue, but I don't necessarily want that now to be part of the repo every time someone clones it.

> Except PRs, bug reports etc. can't affect the runtime behavior of your program, only code can

Are your repos free of docs, READMEs and tests, then?

> I just definitely don't want it cluttering up the history of my code

Separate branch?

> I often want to allow pretty much anyone to open a PR or an issue, but I don't necessarily want that now to be part of the repo every time someone clones it.

That is a good point; perhaps solvable by having the webapp frontend provide the GUI but make commits itself? That should give you the best of both worlds.

Fossil keeps them in the same repo but as a separate kind of object.

It's not the case, the PRs, bug tracking and other metadata are stored inside an SQL database:

Here are the tables on my at home deployment:

  mysql> show tables
      -> ;
  +---------------------------+
  | Tables_in_gogs            |
  +---------------------------+
  | action                    |
  | attachment                |
  | collaboration             |
  | comment                   |
  | commit_status             |
  | deleted_branch            |
  | issue                     |
  | issue_assignees           |
  | issue_user                |
  | milestone                 |
  | mirror                    |
  | notice                    |
  | notification              |
  | oauth2_application        |
  | org_user                  |
  | protect_branch            |
  | public_key                |
  | pull_request              |
  | release                   |
  | repo_indexer_status       |
  | repository                |
  | review                    |
  | star                      |
  | stopwatch                 |
  | task                      |
  | team                      |
  | topic                     |
  | tracked_time              |
  | update_task               |
  | upload                    |
  | user                      |
  | watch                     |
  | webhook                   |
  | [...]                     |
  +---------------------------+
  67 rows in set (0.01 sec)

Edit: delete a few lines in the list of tables, it was way too long for an HN post...