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

> just not try to maintain referential integrity but instead suck up the issues from Git into a local SQLite3 DB

Applications with SQL backends tackle the problem “how can we express our CRUD datastructures so they fit the relational model?

When you replace SQL with a file-based serialised format, you mainly lose ACID. This is arguably easier than SQL.

You are a single user locally: as long as your IDE plugin doesn’t fight with your terminal client, your need for ACID are low: you handle conflicts like git conflicts, but you may apply domain-specific conflict resolution; while conflicts in source code has no general resolution strategy, merging issue comments can be easy; changing issue status when people agree can be automatically resolved; handling conflicts manually can be tool-assisted.

So losing SQL is not that big of a deal, assuming you’re in a highly decentralised, highly async environment.

The answer to “Why though?” should be forge interop, keeping knowledge in-repo, and because it may fit the organisation (or lack of), e.g. just like you can commit code changes offline, you’re not prevented from updating issues when you’re offline.