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

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

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

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>

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

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.

Someone is taking lessons from fossil-scm.

Looks great by the way.

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.

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)

excellent! will definitely give this a try

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

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?

[flagged]

[dead]