4 ms·

P.S. The GitHub readme for this project desperately needs a "Why?" (... would anyone use it, ie. what benefits does it offer vs. say Jira?)

jFriedensreich 1y ago
I think this is made for an audience who find it obvious. "Why would you do it any other way" would be more interesting: There is a weird divide between git supported features on one hand and pull requests/ merge requests/ patch lists/ issues/ bug trackers etc. If everything was supported in git all these features would be interoperable between forges like github, bitbucket and gitea, forgejo. Not only interoperability but backups, tooling, distributed workflows and everything in between would work consistently and the same way. That said, I cannot count the times this concept was brought up and tried to make work but despite how much i love the idea in theory, i have yet to see a way it could work in practice. Some of the issues: - no universal agreement on exact schema, feature set and workflows, do the competing implementations break each other? if its not interoperable why even bother vs just using an external solution - how to handle issues not associated to one specific repo or to multiple repos, splitting repos etc. - how to not confuse devs seeing issue branches or wherever the actual data is stored in the repo - how to best make this usable to non devs The list goes on
- cryptonector 1y ago
  > "Why would you do it any other way" would be more interesting: That's the interesting question. Normally a bug tracker would basically be a SQL application. When you move it into a Git repo you lose that and now you have to think about how to represent all that relational data in your repository. It gets annoying. This is why for Fossil it's such a trivial thing to do: Fossil repositories _are_ relational and hosted on an RDBMS (SQLite3 or PG). If you don't have a SQL then referential integrity is easy to break (e.g., issues that refer to others that don't know they're being referred to), and querying your issue database becomes a problem as it gets huge because Git doesn't really have an appropriate index for this. What one might do to alleviate the relational issues is to just not try to maintain referential integrity but instead suck up the issues from Git into a local SQLite3 DB. Then as long as there are no non-fast-forward pushes to the issues DB it's always easy to catch up and have a functional relational database.
  - Git-Master 1y ago
    Two corrections: 1. Fossil repositories are explicitly not relational, they are however stored in SQLite databases. The data model for everything SCM-relevant (that also includes all content like tickets, wiki, forum) is stored as artifacts in a blob table (+ delta), which references other artifacts by hash value, and that provides the referential integrity. That, and the code that handles it. There are relations (via auxiliary tables) to speed up queries, but these tables are transient, get updated by inserting new artifacts, and can be regenerated from the artifacts. (Users and their metadata, and configuration is not part of this scheme, so these tables might be viewed as relational tables. They are local-only; and not synced.) See https://fossil-scm.org/home/doc/trunk/www/fossil-is-not-relational.md https://fossil-scm.org/home/doc/trunk/www/fossil-is-not-rela... and https://fossil-scm.org/home/doc/tip/www/theory1.wiki https://fossil-scm.org/home/doc/tip/www/theory1.wiki for more details. 2. There are no other databases like PostgreSQL to choose from.
    - cryptonector 1y ago
      I get that the auxiliary tables speed up queries, but the data is relational in nature on some level. I thought that Fossil did or at least aimed to support different SQL RDBMSes. Did that go away at some point?
      - chungy 1y ago
        Fossil's "file format" is not intimately tied to SQLite: https://fossil-scm.org/home/doc/trunk/www/fileformat.wiki https://fossil-scm.org/home/doc/trunk/www/fileformat.wiki That being said, it's the only existent implementation and none other are planned. If you'd like to port it to PostgreSQL, go for it, but it probably would lose a lot of the appeal of being a distributed version control system.
  - jFriedensreich 1y ago
    I don't think that is the main issue. Its not THAT hard to build a secondary sqlite index for data stored in git and keep in in sync especially because the data is already versioned and can be incrementally updated.
cryptonector 1y ago
It's obvious. It's also not original. There are multiple things like this already. Fossil was the first tool to put bug tracking in the repository. Idk which VCS/forge was the first to put wikis in the repository, but it might have been GitHub or Fossil. The point here is to be able to work with issues, PRs, and wikis offline just as one is now used to doing with code. And to use the same underlying content-addressed version control tooling for all those things.
- freddie_mercury 1y ago
  > Fossil was the first tool to put bug tracking in the repository I'm pretty sure Aegis did it 15 years before Fossil.
tasuki 1y ago
> what benefits does it offer vs. say Jira? Not being Jira is already a huge benefit. It says offline, local first. Isn't that nice?

jFriedensreich 1y ago

I think this is made for an audience who find it obvious. "Why would you do it any other way" would be more interesting: There is a weird divide between git supported features on one hand and pull requests/ merge requests/ patch lists/ issues/ bug trackers etc. If everything was supported in git all these features would be interoperable between forges like github, bitbucket and gitea, forgejo. Not only interoperability but backups, tooling, distributed workflows and everything in between would work consistently and the same way. That said, I cannot count the times this concept was brought up and tried to make work but despite how much i love the idea in theory, i have yet to see a way it could work in practice. Some of the issues: - no universal agreement on exact schema, feature set and workflows, do the competing implementations break each other? if its not interoperable why even bother vs just using an external solution - how to handle issues not associated to one specific repo or to multiple repos, splitting repos etc. - how to not confuse devs seeing issue branches or wherever the actual data is stored in the repo - how to best make this usable to non devs The list goes on

cryptonector 1y ago
> "Why would you do it any other way" would be more interesting: That's the interesting question. Normally a bug tracker would basically be a SQL application. When you move it into a Git repo you lose that and now you have to think about how to represent all that relational data in your repository. It gets annoying. This is why for Fossil it's such a trivial thing to do: Fossil repositories _are_ relational and hosted on an RDBMS (SQLite3 or PG). If you don't have a SQL then referential integrity is easy to break (e.g., issues that refer to others that don't know they're being referred to), and querying your issue database becomes a problem as it gets huge because Git doesn't really have an appropriate index for this. What one might do to alleviate the relational issues is to just not try to maintain referential integrity but instead suck up the issues from Git into a local SQLite3 DB. Then as long as there are no non-fast-forward pushes to the issues DB it's always easy to catch up and have a functional relational database.
- Git-Master 1y ago
  Two corrections: 1. Fossil repositories are explicitly not relational, they are however stored in SQLite databases. The data model for everything SCM-relevant (that also includes all content like tickets, wiki, forum) is stored as artifacts in a blob table (+ delta), which references other artifacts by hash value, and that provides the referential integrity. That, and the code that handles it. There are relations (via auxiliary tables) to speed up queries, but these tables are transient, get updated by inserting new artifacts, and can be regenerated from the artifacts. (Users and their metadata, and configuration is not part of this scheme, so these tables might be viewed as relational tables. They are local-only; and not synced.) See https://fossil-scm.org/home/doc/trunk/www/fossil-is-not-relational.md https://fossil-scm.org/home/doc/trunk/www/fossil-is-not-rela... and https://fossil-scm.org/home/doc/tip/www/theory1.wiki https://fossil-scm.org/home/doc/tip/www/theory1.wiki for more details. 2. There are no other databases like PostgreSQL to choose from.
  - cryptonector 1y ago
    I get that the auxiliary tables speed up queries, but the data is relational in nature on some level. I thought that Fossil did or at least aimed to support different SQL RDBMSes. Did that go away at some point?
    - chungy 1y ago
      Fossil's "file format" is not intimately tied to SQLite: https://fossil-scm.org/home/doc/trunk/www/fileformat.wiki https://fossil-scm.org/home/doc/trunk/www/fileformat.wiki That being said, it's the only existent implementation and none other are planned. If you'd like to port it to PostgreSQL, go for it, but it probably would lose a lot of the appeal of being a distributed version control system.
- jFriedensreich 1y ago
  I don't think that is the main issue. Its not THAT hard to build a secondary sqlite index for data stored in git and keep in in sync especially because the data is already versioned and can be incrementally updated.

cryptonector 1y ago

It's obvious. It's also not original. There are multiple things like this already. Fossil was the first tool to put bug tracking in the repository. Idk which VCS/forge was the first to put wikis in the repository, but it might have been GitHub or Fossil. The point here is to be able to work with issues, PRs, and wikis offline just as one is now used to doing with code. And to use the same underlying content-addressed version control tooling for all those things.

freddie_mercury 1y ago
> Fossil was the first tool to put bug tracking in the repository I'm pretty sure Aegis did it 15 years before Fossil.

tasuki 1y ago

> what benefits does it offer vs. say Jira? Not being Jira is already a huge benefit. It says offline, local first. Isn't that nice?