Git-bug: Distributed, offline-first bug tracker embedded in Git

Original Article ↗ Hacker News Discussion ↗

A new tool called git-bug embeds an offline-first, distributed bug tracker directly into Git repositories, aiming to keep issues versioned and portable alongside the code itself. Commenters weigh its benefits—self-contained projects, no SaaS dependency, CRDT-based conflict resolution, and potential extensions like pull requests and CI—against practical challenges such as usability for non-technical stakeholders, identity management, SSH integration, and the limits of tying tickets too closely to branches. Comparisons with systems like Fossil, Gerrit, and traditional centralized trackers highlight a broader question of whether issue tracking can be effectively decentralized without sacrificing accessibility and workflow simplicity.

Overall reception & concept

  • Many find the idea of a distributed, offline-first issue tracker inside Git very appealing, especially for small teams and local-first workflows.
  • People like that issues can travel with the repo, be versioned, and stay independent of any particular SaaS forge.
  • Some argue tickets are integral to code history (especially resolved bugs), making co-location with code attractive.

Naming and scope (“bug” vs “everything”)

  • Several note that “git bug” sounds limiting for feature requests, PRs, and other workflows.
  • Others point out that many historic trackers use “bug” for all issue types, and that’s been fine in practice.
  • The current CLI naming (e.g., potential git bug bug vs git bug pr) is seen as awkward but not a blocker.

Distributed issue tracking challenges

  • Prior attempts at distributed trackers often failed, mainly around merge/conflict handling and collaboration across branches.
  • There’s debate about tying issues to branches vs a shared space; branch-specific issues improve precision but obscure shared status.

Data model, CRDTs, and Git integration

  • The project deliberately avoids raw Git merge conflicts for tickets, using CRDT-style operations instead.
  • Rationale: for social interactions, capturing user intent and avoiding manual conflict resolution is more important than exact text merges.
  • Git’s flexible refs namespace is praised; issues live alongside branches/tags without changing core Git.

Identity and security model

  • Git’s name/email/signature model is deemed too weak for a peer-to-peer, offline-first social system.
  • The project has its own identity layer with public keys and a planned migration to DID-based infrastructure to share identities across repos.
  • There’s discussion of eventually also verifying code commits using these identities.

Usability, accessibility, and web UI

  • Some argue issue trackers must be broadly accessible; tying them to Git/CLI may exclude non-developers.
  • Others suggest a web UI with OAuth/OIDC (and possibly federation standards) is essential so it can feel like a normal hosted tracker while still being local-first under the hood.
  • Desktop apps or dockerized web frontends are proposed to reduce Git exposure for non-technical users.

Networking, SSH, and implementation issues

  • A bug requiring an SSH agent for push/pull is called a “showstopper” by some; others see it as minor.
  • Concern centers on not using the system’s SSH, which breaks complex ~/.ssh/config setups (ProxyJump, multiple identities, bastions).
  • The author indicates plans to fall back to invoking the Git binary (or similar) instead of the current library, possibly by default.

Workflow features and limitations

  • Current binary open/closed status is seen as too limited; there’s interest in configurable states and extensible operations/entities.
  • The data model is designed so new operations/entities can be added without breaking older clients.

Motivation vs centralized services

  • Supporters value independence from SaaS, offline speed, and having an entire project self-contained.
  • Critics argue that centralized web trackers are better for broad access, and that aligning bug lifecycle with Git history is often artificial.
  • One concern: requiring Git permissions (e.g., force-push) for non-coders to edit tickets violates existing role boundaries.

Monetization and ecosystem

  • Turning this into full-time work is considered difficult; selling to enterprises is seen as hard.
  • Some suggest niches: hobby projects, LLM-friendly repos, or an “enterprise” tier with support.
  • There’s active discussion of extending to pull requests, CI, and forge-like capabilities.

Alternatives and related projects

  • Multiple prior art and sibling tools are referenced: Fossil, other Git-based trackers, review systems, CRDT-based metadata forges, and file-based ticket systems.
  • Fossil is cited as evidence that an integrated VCS+tracker can work well, though its strong opinions (e.g., no history rewriting) limit adoption for some.
  • Some users prefer simpler, text- or JSON-based trackers stored in dedicated branches or repos, arguing for separation of concerns and minimal magic.