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

Hi, author here, nice to see some interest :-)

FYI, this is my near-term roadmap:

  - have the webui accept external auth (like github oauth) so that it can be a public portal and accept external interactions
  - have the webui expose a git remote endpoint
  - slightly rework identities (and likely root them in did:plc for pubkey distribution, the identity system from bluesky, without being an ATProto thing), which would allow to share identities between repos way more naturally
  - extend to support pull-requests, possibly CI. That would make it a somewhat complete local-first forge that you can also self-host trivially

Also, while there is some attention ... I'm considering working on this full time. If you have some advice or opportunities on how I can support myself doing this, let me know!

You can also do code reviews in pure git:

https://github.com/google/git-appraise

I used git bug before but found I missed being able to edit tickets with a Markdown editor. So I built this: https://github.com/LoumTechnologies/ticketry

I tried git-bug a few months ago, and https://github.com/git-bug/git-bug/issues/1023 is a showstopper.

There is a workaround, but it isn't pretty. You can push/pull bugs and identities with normal, ssh-agent-less git commands: https://gist.github.com/parasyte/80ef925d4b01216f6bcb051356f...

Just for those people for whom this might be a new concept: There is actually a fair number of these distributed bug trackers: <https://news.ycombinator.com/item?id=22833037>

A few months ago there was another of these posted, called Epiq: https://news.ycombinator.com/item?id=48155570

My comment on there is about a surge in popularity of these over a decade ago, with a link to a previous comment about problems I remember them having that prevented them from being usable for most people ( https://news.ycombinator.com/item?id=47956979 ), because of their intended design rather than an implementation issue. For example bullet 3 was a problem in one, that another tried to solve with bullet 2.

I don't have time right now to look at this one to guess if these apply, but might be interesting/useful for someone else.

My favorite VCS friendly ticket tracker is https://github.com/wedow/ticket

It's human-readable, simple, and easy to work with. Basically there's no magic.

Awesome project. When I was using sourcehut, I have written a primitive script that lets you import issues into git-bug. Maybe it's useful to someone: https://paste.sr.ht/~mfl/0b4949c7675cd04490c95cb676f3821c710...

Someone is taking lessons from fossil-scm.

Looks great by the way.

This is a really cool project, and I would love to see Magit add support for this. I do have one constructive criticism though, take it or leave it.

I would not say git-bug is "embedded" in Git. It follows Git's command naming convention, so it is resolved by the Git cli if it is found on $PATH. I would say that git-bug integrates with git's workflow and uses git's storage. I think it would be less confusing if the claim were: git-bug is fully integrated with Git, or something similar to that. To say that it is "embedded" implies that the binary is loaded through a plugin or extension mechanism more directly than a command-convention lookup.

b4 maintainer and Director of LF IT Konstantin Ryabitsev demo-ed git-bug support in b4 and cgit (kernel.org fork) just this week at the Kernel Recipes conference:

https://b4.docs.kernel.org/en/latest/maintainer/bugs.html

https://git.kernel.org/pub/scm/utils/b4/b4.git/bugs/

https://kernel-recipes.org/en/2026/2026/09/22/live-blog-day-... (shameless plug)

Git has a wide open reference namespace for these kinds of ideas, and I'm always excited to see someone use it like this.

See, at core git is a collection of objects (referenced by their hash), along with references to tip-of-tree objects. These references are stored in the refs/ directory, and core git only uses a couple subdirs/namespaces under that: refs/heads/ (for branches) and refs/tags/ (for tags). Git also bundles the oft-forgotten git notes command that stores notes in refs/notes/. But you can add whatever other name under refs/ to tack on whatever functionality you want, which is what all these git-based bug-trackers do.

Side-note, Gerrit exploits this wide-open namespace for its behavior, where pushing to the virtual refs/for/ namespace will create a new Change destined for a given branch. It also uses these namespace for its internal NoteDB.

I’ve been saying for years that issue tracking should just be done in git along with the rest of the code. I’ll definitely be checking this out.

Interesting project. What happens when two people file the same bug offline and then push? Does it handle the merge/conflict resolution the same way git handles it for code?

Offline-first bugs living next to the code is a nice fit for tiny teams. Less context switching than opening a separate tracker when you are just shipping a small project.

Can this be used for more than just bugs? I feel like it can but the name is going to be limiting.

Nice! I look forward to digging in to this.

My own slightly-similar thing (uses an explicit sequence, and signed objects in refs/): https://github.com/generalbusiness-ai/gitseq

Interesting approach. Curious how this compares to just using GitHub Issues for teams that are already git-centric — what's the main pain point this solves that Issues doesn't?

I don't quite get the problem this tries to solve.

I'm not quite sure that the bug list is the integral part of the source code. And there are dedicated systems that work just fine.

And if I really feel like tagging bug tracker along with my code, I could use any of those systems as long as they support file based databases, like sqlite, or simply static text files for that matter.

Does it bridge to other repos with “git bug”?

See also: https://github.com/schacon/ticgit

A rare HN post that’s actually interesting. Seems more ergonomic than the offerings from multi billion dollar corporations.

Let’s hope the consultants and/PE don’t ruin this one.

excellent! will definitely give this a try

I considered using something like this, but instead I implemented my own basic JSONL issue tracker, and I keep the issue files in an `issues` branch in Git. This separation of concerns allows simpler design and gives more flexibility (if I want to change either git or the issue tracker, or go without Git altogether, they're not tied together).

Over the years I've noticed that "merging two designs into one" is a design smell. Nearly every technology we still use today has a very clear separation from other technologies, and is instead layered or composed to gain added functionality.

Looks really nice, I wonder why there hasn't been a project with this exact name and functionality before. When I think about it, "git bug" is quite limiting (the bug vs. feature discussion).

Naming things is hard, but I can see that it might feel unnatural to use "git bug" to track features. Maybe that's totally okay because it does one thing - tracking bugs - very well, and the whole feature roadmap is living in another system/process anyways?

see also: https://github.com/dspinellis/git-issue

To me, tickets need to be too broadly accessible for anything like this to be viable. Any barrier to entry to creating tickets means people aren’t filing them. Every role at every level looks at them and edits them.

Yeah yeah we don’t want a centralized service, but it’s the ideal use case for a centralized service.

[flagged]

[dead]

[flagged]

[flagged]

[flagged]

[dead]

[dead]

Looks like GitHub issue tracker is embedded in git itself. Interesting!

"you only need your git repository to have a bug tracker"

What if my git repo doesn't have a bug tracker?