Pimp My IDE / Garage Dispatch
Back to garage
September 25, 2026 | issue tracking / Git / offline tools

Make the issue log travel.

Code can survive a dead service, a bad connection, or a platform move. The decisions around that code should not be easier to lose than the branch.

The take: git-bug stores issue history in Git objects and synchronizes it through Git remotes. That gives the tracker a strong transport story. Teams still need explicit rules for identity, accepted remotes, bridge behavior, and export tests.
Set the Issue Hitch Coupler

The tracker can ride with the code.

git-bug is an offline-first issue tracker embedded in Git. Its native workflow uses git bug push and git bug pull. It can also bridge issues to GitHub, GitLab, Jira, and Launchpad. The project offers a CLI, a terminal interface, and a work-in-progress web interface.[1]

The important detail is below the interface. git-bug stores edit operations in Git blobs. Trees link those operations and any attached media. Commits form the history, and references under a separate namespace make that history available to a Git remote.[2]

The issue log stops being a website beside the repository. It becomes repository data with its own history.

Offline is an operating property.

Offline work is useful before a dramatic outage. It gives a developer or coding agent a local issue list with fast search, comments, and status changes. A bridge can synchronize those changes with an external tracker later.[3]

The idea has reached another serious toolchain. The b4 project now documents an alpha b4 bugs interface driven by git-bug. Its docs say bug objects travel with the code through Git push and pull. The same page labels the feature a technology preview. Both facts matter.[4]

Portable does not mean governed.

Git supplies content-addressed storage and transport. Git's own documentation describes the object database as a key-value store that returns a key for inserted content.[5] That mechanism does not decide which remote is authoritative, who may create an identity, how bridge conflicts should be reviewed, or whether an export can rebuild the working issue set.

Repository-native tracking also changes the review surface. Issue objects and media add data to the repository even though git-bug does not add files to the project tree. Teams need storage, retention, moderation, access, and backup rules that match the actual refs and remotes.

Couple transport to a policy card.

Start with one of three routes:

  1. Local for private notes and disconnected work.
  2. Native remote for teams that accept Git as the issue transport.
  3. Bridge for teams that keep an external tracker as the public or authoritative interface.

Then name the four policy slots that make the route reviewable: object namespace, identity rule, accepted remote, and replayable export. The coupler below writes that plan. It does not configure git-bug, validate signatures, synchronize a bridge, or prove a restore.

Interactive makeover / issue policy

Issue Hitch Coupler.

Traditional purpose replaced: a tracker URL and an assumed backup. Better version: choose the route, select the policy slots, and copy a handoff that keeps transport claims separate from tested evidence.

Choose the issue route

Native radio controls own the route. The carriage only displays that choice.

Issue transport route
Select the policy slots
LOCAL / DRAFT1 / 4 SLOTS SELECTED

The objects have no shared authority yet.

The object policy slot is selected. Identity, remote, and replay remain open.

RouteLocal. No shared remote or external tracker is selected.
Completion claim1 of 4 policy slots selected. No transport or recovery test has run.
This teaching control writes a policy template. It does not inspect a repository, create an identity, push refs, call a bridge, or restore issue data.

Copy the route card

Fill and test after copyingAdd the real repository, namespace, identity method, remote, bridge target, export path, command output, and reviewer. Selected slots describe template structure only.

Sources read, not vibes

Open the source log
  1. git-bug repository and README: product scope, CLI commands, native and bridge workflows, terminal and web interfaces, supported bridges, known web-interface status, internals, and license.
  2. git-bug data model: operation packs, Git blobs, trees, commits, refs, logical clocks, identifiers, and deterministic merging.
  3. git-bug bridge documentation: bidirectional incremental synchronization, supported services, configuration, tokens, push and pull commands, and local archive claims.
  4. b4 end-user docs, "bugs: bug tracking with git-bug": alpha status, installation, TUI and CLI scope, Git object storage, and Git remote transport.
  5. Pro Git, "Git objects": Git's content-addressed key-value object store and object inspection.
  6. Hacker News item 49843174: exact discovery thread for the current git-bug discussion.

Source boundary: git-bug describes its own implementation and workflows. b4 documents an alpha integration and does not certify git-bug for every project. Pro Git explains the storage mechanism, not team governance. Hacker News is the discovery trail. The Issue Hitch Coupler is our policy pattern.