Build1 publisher2 min readPublished
git-bug 0.11.0 keeps a repo's issues in git refs that sync over the existing remote
git-bug 0.11.0, its first release in 16 months, stores a repo's issues as git commits under refs/bugs and syncs them over the existing remote. When GitHub's web issue creation failed on September 13, repositories kept working, and git traffic is all this tracker needs.
The Engineer · Build desk
What happened
- On September 13, GitHub's status page showed 96% of web issue-creation attempts failing for about two hours, a dev.to walkthrough of git-bug reports.
- git-bug shipped version 0.11.0 on September 22, its first release in 16 months, carrying close to 300 commits.
- The tool stores each bug as a chain of git commits under a refs/bugs ref, and in testing it left git status clean with no new tracked files.
- git-bug has no accounts and no server, and each user identity is a signed git object.
- The walkthrough ran every command against the release binary on a scratch repository and says it is not a production team story.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- capability A blocker can be recorded in the local repository with no tracker server reachable, then pushed when the remote answers.
- constraint Audit scripts that read git commit authors will find an empty field on git-bug's commits, so attribution has to come from its identity objects.
- decision Before a team moves its issues into refs, the result to check is how concurrent offline edits to one bug come out after a two-node sync.
Every edit in git-bug is an operation. A comment, a label change or a status flip each becomes one entry in the JSON operation packs held in the bug's commits. The bug's current state is computed by replaying those operations in order [6][7]. The project documents the design as an operation-based CRDT stored in git objects, and it publishes a formal specification of the on-disk format in its own repository [7]. A written storage spec for a bug tracker is good engineering. You only need plain git plumbing to inspect the result: `git cat-file -p` on a bug's ref prints an ordinary commit with a tree and a parent [8].
That commit's author line reads `author <>`, so git's own author field records nobody [8]. git-bug keeps identity in separate signed git objects [5].
Installing it costs little. The release is one static binary, packaged as tar.gz, deb, rpm, apk and Arch [12]. It registers as a git subcommand, so `git-bug` and `git bug` both work inside whatever repository you are standing in [13].
The outage argument depends on what broke on September 13. By the walkthrough's account, code repositories were fine while the issue tracker was not [2]. git-bug syncs over the existing git remote [4], and the walkthrough ran new, list, comment, label and close with no server running [9]. The host dependency stays. With a GitHub remote, sync still goes through GitHub. On that day, git-bug's advantage would have rested on git serving staying up while the issues feature failed [2][4]. Version 0.11.0 shipped nine days after the outage [15].
The 91 ms cold round trip for `git bug bug show` [11] was measured on the walkthrough's scratch repository [10]. For that figure to hold on a real project, replaying each bug's operation log would have to stay cheap at the history length a long-lived tracker builds up. The scratch-repository session did not cover that. It did run a two-node sync with an offline edit on each side [10]. That is the case behind the walkthrough's own question about two people editing one bug offline [16].
What to watch
- GitHub's incident report for September 13, to confirm that git push and fetch stayed healthy while web issue creation failed.
- Whether a plain git clone of a repository brings its refs/bugs data along, one of the questions the walkthrough poses.