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

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

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.