Comment by ncmncm

6 years ago

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?

7 comments

ncmncm

Reply
hn_throwaway_99  6 years ago

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.

  • Vinnl  6 years ago

    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.

  • ncmncm  6 years ago

    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.

    • hn_throwaway_99  6 years ago

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

      1 reply →

kakwa_  6 years ago

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