88 points alentred 2 hours ago 20 comments
lolakutty 1 hour ago | parent
Looks great by the way.
bflesch 1 hour ago | parent
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?
dizhn 1 hour ago | parent
Meneth 1 hour ago | parent
michaelmure 30 minutes ago | parent
Naming is hard, but I mostly didn't expect to reach that point :-)
Aissen 1 hour ago | parent
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)
mcepl 11 minutes ago | parent
saadn92 59 minutes ago | parent
Izkata 59 minutes ago | parent
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.
lelanthran 43 minutes ago | parent
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.
teddyh 45 minutes ago | parent
mcepl 12 minutes ago | parent
michaelmure 38 minutes ago | parent
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!delf 27 minutes ago | parent
sebiw 24 minutes ago | parent
> 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!
imagent 24 minutes ago | parent
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