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.
- 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!
> - have the webui accept external auth (like github oauth) so that it can be a public portal and accept external interactions
Have you looked into ForgeFed? It's a WIP plan for different Forgejo based forges to federate with each other. https://forgefed.org/
There's also this: https://indieauth.net/ though I haven't looked into it. I hope you could integrate one of these into your planned OAuth/account system!
First of all: Huge respect for getting something out the door, looks really useful.
> 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 could consider an "enterprise" tier with a special subset of features and guaranteed support. But my experience tells me this will be really hard to substantially monetize, as the customer profile for that solution is probably not spending on software until they really need to (the saying goes: selling to developers is impossible, you need to sell to their boss). Maybe a donation model or a creator-centric thing could work out!
Yeah I agree that monetization seems hard here. But one niche that might work - tons of people are using LLMs to build out side projects and keeping tickets in the same repo as the project could be really frictionless for LLMs to reach for without an MCP server.
Don't sell to developers for their day jobs, but sell to developers for their hobbies.
No mention of Fossil, which works great and proves that the difficulty is in gathering dev interest.
It may be that the presence of Fossil as a mature option is enough to dissuade people from choosing/working on alternatives. I’m pleased to see git-bug slowly making progress though, maybe it will get there in time.
I looked into them. Most of them use some CRDT-ish machinery to merge concurrent ticket changes. (Fixing merge conflicts in tickets would be too disappointing.) As a CRDT person, I noticed that implementing CRDT merges in git itself mostly makes that machinery unnecessary. Then you can keep your tickets in plain Markdown, having CRDT merges for both code and metadata. I have it working here btw
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.
Other than the first bullet point in your list[1], my contribution in this regard addresses everything else.
Don't have a link handy but it's on github called "rotsit" (revenge of the something issue Tracker).
‐----‐------
[1] That's the entire point of having the issue tied to a branch: if an issue is marked resolved in the branch you are looking at, then its resolved in the branch you are looking at. Storing the issues independent of branch means you need to also store extra metadat about which branch it is broken on.
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:
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.
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.
I agree. I'll have soon-ish the webui accept OAuth/OIDC, so you can easily host and replicate a normal bug tracker experience... yet still benefit from the other workflows that a normal forge can't have.
That's the key feature to make a distributed bug tracker actually work in practice.
Wouldn't it require constantly pushing/fetching? Or would it effectively be like a hosted thing with a service layer on top of git showing a live view of the repo's tickets? Like github but for tickets... oh wait...
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?
I do want to extend to pull-request and more, so I'll need to at least make space in the CLI commands. Having a "git bug bug" next to a "git bug pr" is quite ugly.
Naming is hard, but I mostly didn't expect to reach that point :-)
Don't overthink it! `git bug bug` is fine - it's easy to type and becomes muscle memory quickly. Love the project, my first impression is "why hasn't this existed the entire time?" which usually means you're on to something.
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...
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.
FYI, this is my near-term roadmap:
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!Have you looked into ForgeFed? It's a WIP plan for different Forgejo based forges to federate with each other. https://forgefed.org/
There's also this: https://indieauth.net/ though I haven't looked into it. I hope you could integrate one of these into your planned OAuth/account system!
> 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 could consider an "enterprise" tier with a special subset of features and guaranteed support. But my experience tells me this will be really hard to substantially monetize, as the customer profile for that solution is probably not spending on software until they really need to (the saying goes: selling to developers is impossible, you need to sell to their boss). Maybe a donation model or a creator-centric thing could work out!
Don't sell to developers for their day jobs, but sell to developers for their hobbies.
https://gitsocial.org/
I'm thinking mostly of Gerrit, which keeps the entire code review and change history in git as well.
Being able to keep literally everything in the same git repo seems highly appealing.
It's human-readable, simple, and easy to work with. Basically there's no magic.
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
It may be that the presence of Fossil as a mature option is enough to dissuade people from choosing/working on alternatives. I’m pleased to see git-bug slowly making progress though, maybe it will get there in time.
I looked into them. Most of them use some CRDT-ish machinery to merge concurrent ticket changes. (Fixing merge conflicts in tickets would be too disappointing.) As a CRDT person, I noticed that implementing CRDT merges in git itself mostly makes that machinery unnecessary. Then you can keep your tickets in plain Markdown, having CRDT merges for both code and metadata. I have it working here btw
https://replicated.live/blog/meta
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.
Don't have a link handy but it's on github called "rotsit" (revenge of the something issue Tracker).
‐----‐------
[1] That's the entire point of having the issue tied to a branch: if an issue is marked resolved in the branch you are looking at, then its resolved in the branch you are looking at. Storing the issues independent of branch means you need to also store extra metadat about which branch it is broken on.
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.
Looks great by the way.
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)
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.
What if my git repo doesn't have a bug tracker?
Yeah yeah we don’t want a centralized service, but it’s the ideal use case for a centralized service.
That's the key feature to make a distributed bug tracker actually work in practice.
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?
It's also a denial of service, since the feature doesn't work yet, and thus should get assigned a CVE.
Naming is hard, but I mostly didn't expect to reach that point :-)
Only once it gets fixed does it become a feature.
;)