- 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!
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!
Yep, I looked into them. Most of them do some CRDT-ish machinery to merge concurrent ticket changes. (Fixing merge conflicts of tickets would be too disappointing.) As a CRDT person I can only notice that implementing CRDT merges for git per se mostly makes those machineries unnecessary. You can keep your tickets in plain Markdown then, no special machinery. 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.
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.
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:
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 :-)
Hi, author here, nice to see some interest :-)
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!
Git-bug looks amazing! Author of GitSocial here, would love to hear your opinion:
https://gitsocial.org/
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!
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>
And none of them actually work really well. This blog post is over ten years old, but the situation didn’t improve much https://matej.ceplovi.cz/blog/current-state-of-the-distribut...
Yep, I looked into them. Most of them do some CRDT-ish machinery to merge concurrent ticket changes. (Fixing merge conflicts of tickets would be too disappointing.) As a CRDT person I can only notice that implementing CRDT merges for git per se mostly makes those machineries unnecessary. You can keep your tickets in plain Markdown then, no special machinery. I have it working here btw
https://replicated.live/blog/meta
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.
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.
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.
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.
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)
Wow! Was this sent upstream to cgit?
A quick checks shows that it seems so, last month. No answer to the RFC yet, though.
excellent! will definitely give this a try
Looks like GitHub issue tracker is embedded in git itself. Interesting!
Who knows how many things GitHub does are actually embedded into git itself :)
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?
Their logo is a ladybug so everything works out in the end.
Isn't everything nowadays a bug?
Only once it gets fixed does it become a feature.
;)
Although if it doesn't get fixed, it also sometimes becomes a feature.
Bugzilla has been using the term "bug" to track features for nearly 3 decades now. Doesn't seem to hamper them.
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 :-)