I built git-native-issue (https://github.com/remenoscodes/git-native-issue), a distributed issue tracker that stores issues as Git commits under refs/issues/.

In April 2007, during a flame war about the Linux 2.6.21 release, Linus wrote:

"There must be some better form of bug tracking than bugzilla. Some really distributed way of letting people work together, without having to congregate on some central web-site kind of thing. A 'git for bugs', where you can track bugs locally and without a web interface."

Source: https://lore.kernel.org/all/alpine.LFD.0.98.0704290848360.99...

19 years later, nobody shipped this. 10+ tools tried (Bugs Everywhere, ticgit, git-bug, git-dit, git-appraise, git-issue). All failed for similar reasons — mostly file-based storage that breaks on merge, and no format spec for ecosystem adoption.

The core insight: issues are append-only event logs, and Git is a distributed append-only database. So I mapped issue tracking directly to Git primitives:

  - Commits = issue events (creation, comments, state changes)
  - Refs = issue identity (refs/issues/<uuid>)
  - Trailers = structured metadata (same format as Signed-off-by)
  - Merge commits = conflict resolution
  - Fetch/push = sync

Usage:

  $ git issue create "Fix login crash" -l bug -p high
  $ git issue ls -f full
  $ git issue show a7f3b2c
  $ git issue sync github:owner/repo

The architecture follows Git's own philosophy: the core only knows commits, refs, and trailers. Platform bridges (GitHub, GitLab, Gitea/Forgejo) are separate scripts that translate between APIs and git primitives. New platform = new bridge, core doesn't change.

The real deliverable is ISSUE-FORMAT.md — a standalone spec that any tool can implement. If this project dies tomorrow, the spec survives. That's the key difference from prior art: none of them produced a standalone format specification.

282 tests across 22 suites. POSIX shell, zero dependencies beyond Git for the core. Platform bridges need jq + their respective CLIs (gh, glab, or curl for Gitea/Forgejo).

Honest limitations: shell is slow with large repos (10k+ issues work but not fast). A C rewrite is on the roadmap, inspired by the path git-subtree took into contrib/.

Feedback I'm looking for: Is the format spec (ISSUE-FORMAT.md) clear and implementable? What edge cases did I miss? Would you actually use this?

Install:

  brew install remenoscodes/git-native-issue/git-native-issue
  # or
  curl -sSL https://raw.githubusercontent.com/remenoscodes/git-native-issue/main/install.sh | sh