- 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!
> 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!
Make it easy for non-technical users to also use this software. That will probably get you further along with gaining paid customers, IMO, because that's the hard part with something like this. It's easy for anyone who isn't used to `git` to use GitHub issues or something like Jira or Shortcut, but something tied to `git` or another cli tool is a hard sell for non-programmers, I think.
Make a program users can install on their MacOS/Windows desktop that interacts with a repository, without any need for the user to use `git`, or make a secure/hardened docker image that an org can run in their infra that links to repos and allows interaction via the web.
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.
> - 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!
Thank you for working on this, I love the idea. What surprised me was the way user identities is managed, I assumed you’d use whatever git uses. Would you mind elaborating on that?
Identities in git can barely be called that. You define your name and email, maybe sign your commit. Those signature can be checked but it's really optional and often left to another system (e.g. github or your git viewer). Access right in the git remote is also a completely different thing.
In a distributed/p2p system with social interaction you need well defined identities that carries public keys. If you want to work offline, you actually need a full self-certified history of public key updates. Any changes in the entities (bug, pr, ...) need to have an author and a clear logical time so that you can backtrack to which pubkey(s) was active at the moment. Note that if you accept external contribution from a webui, you still need those identities being created in the background, possibly later to be "adopted" when using the native tooling.
Identities in git-bug is a part that nearly didn't change since the inception, and it's time for an upgrade. At the moment they are a linear series of changes (that is, NOT a CRDT) and are stuck within one repo. You can push/pull around but you are really just making a copy that you need to maintain.
My plan is to split this concept in two parts: pubkey log, and how they anchor within the repo's logical time. It turns out that if you split that way, the first part is pretty much exactly what did:plc is. Additionally, for complicated reasons like allowing recovery without opening major weakness, that's the one thing where having a centralized reference is important, so relying on the public https://plc.directory/ makes sense.
> In a distributed/p2p system with social interaction you need well defined identities that carries public keys. If you want to work offline, you actually need a full self-certified history of public key updates.
I don't understand how this is a problem. Isn't this already solved with keyservers and importing to a local keyring? My Linux distro has no problem keeping track of who is who and if they are trusted (not updating for a year or two would probably break things).
> so that you can backtrack to which pubkey(s) was active at the moment
I think GitHub solves this by simply checking at the time of the push and then never again (which is why you can change the keys without de-verifying older commits. Doesn't git's design yield blockchain-like assurance that nothing in the past has been modified?
Personally, I think signed commits should be the default. This is especially true in the age of AI where distinguishing humans from machines becomes harder every day. I would love for encrypted email/IM and sharing keys to be the norm for everyone but we're not there and may never be.
> I don't understand how this is a problem. Isn't this already solved with keyservers and importing to a local keyring? My Linux distro has no problem keeping track of who is who and if they are trusted (not updating for a year or two would probably break things).
There is different pieces that solve part of the problem (name/email from the git config, key servers for *some* users), but everything is disconnected, unstable, incomplete. Git-bug needs a stable identifier, the full self-certified pubkey log ... Those solutions are not good enough.
> Doesn't git's design yield blockchain-like assurance that nothing in the past has been modified?
It's not specific to git, but yes you get a chain of data blocks, content-addressed with signature support. That's what you want to build on, to have identities, roles, rules to enforce in a p2p system.
> Personally, I think signed commits should be the default. This is especially true in the age of AI where distinguishing humans from machines becomes harder every day. I would love for encrypted email/IM and sharing keys to be the norm for everyone but we're not there and may never be.
Agree! Note that if git-bug bring a solid identity primitive and publish pubkeys ... it can also carry the pubkeys that are *already* used to sign commits, publish them in the same public registry and verify code commits transparently, without relying on a third party to do so. Imho that's something missing in the current git model: if there is identities, there are segregated in third party systems like github. DIDs brings a lot to the table.
It's really hard (impossible?) to define a feature set that work for everyone. Every bug tracker is a bit different, and if you want to have everything you end with Jira, which I'm not sure is actually solving a problem.
However, git-bug's data model is designed in a way that you can add more "operations" on an entity (say: assign a bug) without every client having to implement it. You can also add your own entity type (pr, kanban, ...) the same way. Clients will just ignore that extra data and support what they want. This open the possibility for addons and so on.
For this specific case of the bug states, I want to add a config entity to configure that. You'd start with a reasonable default (open/close) but you could tune it for the needs of your project.
Were you aware of git-bug when you created gitsocial? If so, which patterns did you reuse and which ones did you decide to diverge from? Or would you say the two projects embody fundamentally different visions?
It's deeply interesting to me that you decided to override git conflict-resolution (at least in the 90% of cases) in favor of CRDT conflict-resolution. That sort of decision is not uncommon but I was just kinda wondering -- did the CRDT idea come first or did you try a plain-text format for storing the bugs and you ran into certain common workflows where that wasn't ergonomic? (My first guess would maybe just be appending comments to the ticket -- so like if a ticket is a TOML file, you both append a comment at the end, Git immediately screams about what order should those two comments be in -- instead to make that ergonomic within Git's limitations you have to like, represent the comments as a directory tree with no inherent order and UUIDv4 names, and then Git will say "oh you both put blobs in that tree? that's fine. no conflicts," and then you have to order them by (declared-time, UUID) on the client side.)
What's not quite so clear from what I'm skimming is what you did to alleviate Git's postmodernism. What I mean is, Git just holds a bunch of refs like tags and branches and they all deliberately, inherently have equal valence -- this comes from the history of Linux being developed on an email list, there literally is not "one Linux", there is no truth about "what is the Linux v6.18 kernel" but rather there is a big family of v6.18 Linux kernels and anyone who wants to spin up a new one can literally just grab an existing v6.18 kernel and write a patch and bam, you have a new one. It's the blind sages and the elephant, every sage is correct about what the software is, within their limited ability to perceive what the software does. And this like perennially causes problems, right, people use Git for a modernist thing like CI/CD where at most companies "what's running in prod?" is one of those questions that we don't like to say "well it depends on your perspective, there is no one truth..."
Sorry for the long explainer -- I'm just aware that this is a very idiosyncratic way of phrasing the D in DVCS. But it's like, in concrete terms, do you have clients force themselves to declare a certain repo as their origin, and a certain ref on origin is the blessed Git-Bug ref that they have to push from and pull to? And like the add-on that you've crafted just doesn't let you branch the ticket list and all of that? Or -- the opposite -- do you go all-in on the postmodernism and say "no whether some strange-looking functionality is a 'bug', that is a fact that needs to be added to the holistic perspective of the project, and whether that bug is deemed fixed is a similar fact that, like, if you say you fixed the bug in `dev` it might still be not fixed in `uat` or `prod` -- so the bugs need to be stored in the repo that you're versioning anyways. And we use these CRDTs to give you a bird's eye consistent view of a Bunch of repos and all of their current statuses and all that." Or do you take a third direction that's neither purely modernist "this is the truth" nor purely postmodernist "every branch is true".
The choice to not use git merge handling was there from the beginning, the proper CRDT came a bit later when I understood more the problem and it's possible solutions. From a UX perspective, manually fixing merge conflict is the right thing for code, but it's a different story for social interactions: when the output you operate on is code, you want to precisely control that output. When the output is people understanding each other, you want to capture the intent. It's ok to, in rare case, be a little bit off in edge cases of the conflict resolution. What's not ok is forcing on the user to understand and deal with the problem.
Note that this very question is why some previous attempt at distributed bug tracker failed.
As for the postmodernism of git, I don't know ;-). I'm simply building on top of the lower level git database and leveraging the tools I have (like push/pull). Each bug is essentially its own namespace of operations that get moved around between repos. As with any CRDT, the state of that document get built from what is known at the time.
Your response here regarding CRDT was enlightening and thought provoking to me. Thank you. Really appreciate the distinction of "intent" especially in the context of human social interactions vs. code precision. Very interesting and insightful.
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.
Fossil is very opinionated about some things, in particular, the inability to rewrite history, which makes it a non-option for some. So there's still a niche for Git-based distributed bug tracking.
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
There is an alternative to auto-resolution or fixing low-level git merge conflicts. In my git forge Haxy, I am detecting conflicts in local-first metadata and allowing you to fix them in the UI. This is possible because I am not doing a line-based merge; the issues are stored as a data structure, so I can see what specific parts are in conflict. This allows a much nicer form of conflict resolution than conflict markers in a text file. I demoed this here: https://www.youtube.com/watch?v=kkGUARj5Wdw and here's the project: https://github.com/xit-vcs/haxy
I'll fix that soon. I really wanted to avoid calling the git binary for security reason, but I have to admit that go-git is not robust enough in some cases. I'll have at least the option to use the git binary for push/pull, possibly as a default depending on how it goes.
Isn't "show stopper" a bit dramatic? What is the big problem with an SSH agent? If security is a problem you should probably store your SSH keys on a HSM like a Nitrokey or Yubikey. In which case you need an agent.
The agent requirement is a symptom of a deeper potential issue: not using the system's ssh. Providing built-in as a fast-path option is fine, but ~/.ssh/config can do a lot of useful things, and providing an easy option to say "just use real ssh" lets people have their config just work.
Specifying identify files for specific hosts, using bastion hosts (ProxyJump), etc. For example, my laptop SSH config detects when I'm not on my university network or VPN and adds a ProxyJump through the department bastion host, but connects directly when I'm on the network. Configurations like that break when software makes too many assumptions about how ssh is configured.
ssh_config allows several ways to execute arbitrary shell commands, such as "Match exec" and "ProxyCommand". Specify a program that can detect networks and choose different connections. Then the config file itself wouldn't change.
I use a Yubikey for some of my keys, and I've never used an "agent", don't know how, and don't want to start, unless someone can give me a good reason to
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.
I can somewhat understand your point about issues tied to branch, but have some remaining questions about how this working in practice:
- If I am on a branch where this issue exists and unaddressed, is it easy to find out if there is another branch where this issue has been addressed
- I am on a branch that does not have the issue reported, but know it's reported on another branch -- does that mean the issue doesn't exist on this branch? Is it on the reporter to correctly identify the root branch where the issue was first created? Do you have to somehow merge to make this work "right"?
I haven't actually tried in practice (across a team I mean), but:
> - If I am on a branch where this issue exists and unaddressed, is it easy to find out if there is another branch where this issue has been addressed
I do not have a solution for that.
> - I am on a branch that does not have the issue reported, but know it's reported on another branch -- does that mean the issue doesn't exist on this branch?
The idea was to create issues only on on a separate branch which is constantly merged into master. Then all branches downstream of master will get the issue when they rebase/pull.
Scenarios:
1. You're on branch `x/y/z`, you notice something that should be added to the issue tracker, you stash, switch to `/issues`, add the issue, push, switch back to `x/y/z` and pop.
2. An issue is to be created, the creator clones `/issues`, creates the issue, and pushes.
This way, all issues are on all branches, but only the branch dealing with an issue will update it.
The issue there was collaboration, one person would be on master and see no hint that a case was already being worked on (status, comments, etc all being different until the branch was merged). The other bullets, that put the information in different locations, were attempts to deal with this.
Yeah, ticket is great! I liked it so much I ended up porting it to Python, which I find easier to read than awk/sh, and tweaking the command surface over dozens of iterations of trying to make the design more ‘self-explanatory’ for coding agents.
https://github.com/a3lem/tiquette
(Excuse the vibe-coded README)
Anyway, even though I’m using it every day, I’m beginning to doubt the core idea of tracking hundreds of .md files in git. They get in the way of fuzzy file search, and if you keep closed tickets around in an archive directory, they just pile up endlessly.
Lately I’ve been considering breaking tickets out of VCS entirely or moving them to a dedicated repository just for ticket tracking.
Git bug looks like it might at least handle getting tickets out of the way
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:
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.
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?
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.
I once worked at a company where the chief architect created an actual bug in Jira, the entire text of which was, "X doesn't exist", X being the name of the product which took ~3 years to develop (and yes it was all tracked as dependencies of that one bug).
It’s a variation on the old Lisp technique of debugging the empty program. You start with () (a.k.a. nil), which doesn’t do what you want, so you debug it.
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.
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?
They would be two different bugs (even with the same title). Someone would recognize the duplicate and close one. That would happen less as the time to sync decrease.
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.
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.
There is a certain appeal to not depending on more tools, and there is something elegant about the bug list traveling with revisions, if they are closed when the bug is fixed. So at any point you could go backwards and see known bugs at the time.
This also applies to certain project management flows and statuses.
Right, there are advantages of your defect list riding right along with the code repository itself. The history here is more interesting and keeping it connected to git allows portability options (maybe across network divides).
The resolved bug list in particular is an integral part of the source code history, because it explains the motivation behind the shape of that code.
From my own experience, debugging often means digging into git blame and finding the issues associated with those commits. Having that metadata directly in a repo, not tied to any specific platform, always in sync, is nice.
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...
It's both really. If done well, the same local-first software can be a hosted solution and give you the "github" experience, or work fully locally, or anything in between with different topologies. If you work locally but care about some external sources, it's just a matter of notification, polling or transport. That can be done silently in the background.
Right but it's all this ceremony that kind of all begs the question - why git? What's the motivation behind using git to do all this if the repository (where the code lives) and the tickets (bugs in the product created by building the code), are naturally out of sync? eg in many cases a bug can't be closed until someone verifies it's fixed, which happens after merge. The point at which a bug is marked as verified is arbitrary with respect to the commits and code. It's just a radom point in time as far as git is concerned. To me there's no need for git to be involved in any way and a url to a ticket in a commit message is far superior in terms of tracking
The point of using git is to have a full software project (code, issues, ...) self-contained, without being trapped in or dependent on a SaaS, dead fast and working offline and integrating with all your tooling locally. All that with a single binary and git that virtually everyone use already.
Now what you are talking about seems to be about the lifecycle of a bug. With this model you can replicate the same behavior as on major bugtrackers, or also track some metadata (fix in commit xxx) and compute where the bug is "deployed". But that's a UX/social problem, not a technical one imho.
Sorry I just don't get it. It's a massive problem when a designer needs permission to force push to a repo to update a bug. These boundaries exist for a reason.
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!> 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!
Make it easy for non-technical users to also use this software. That will probably get you further along with gaining paid customers, IMO, because that's the hard part with something like this. It's easy for anyone who isn't used to `git` to use GitHub issues or something like Jira or Shortcut, but something tied to `git` or another cli tool is a hard sell for non-programmers, I think.
Make a program users can install on their MacOS/Windows desktop that interacts with a repository, without any need for the user to use `git`, or make a secure/hardened docker image that an org can run in their infra that links to repos and allows interaction via the web.
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.
To be fair I was also unhappy with current tooling and made my own [0] in a day or so.
I think this tool would be a hard thing to monetise unfortunately in 2026. It’s just… so easy to make stuff now.
[0] https://github.com/tristanmatthias/tasks
[flagged]
> - 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!
Thank you for working on this, I love the idea. What surprised me was the way user identities is managed, I assumed you’d use whatever git uses. Would you mind elaborating on that?
Sure.
Identities in git can barely be called that. You define your name and email, maybe sign your commit. Those signature can be checked but it's really optional and often left to another system (e.g. github or your git viewer). Access right in the git remote is also a completely different thing.
In a distributed/p2p system with social interaction you need well defined identities that carries public keys. If you want to work offline, you actually need a full self-certified history of public key updates. Any changes in the entities (bug, pr, ...) need to have an author and a clear logical time so that you can backtrack to which pubkey(s) was active at the moment. Note that if you accept external contribution from a webui, you still need those identities being created in the background, possibly later to be "adopted" when using the native tooling.
Identities in git-bug is a part that nearly didn't change since the inception, and it's time for an upgrade. At the moment they are a linear series of changes (that is, NOT a CRDT) and are stuck within one repo. You can push/pull around but you are really just making a copy that you need to maintain.
My plan is to split this concept in two parts: pubkey log, and how they anchor within the repo's logical time. It turns out that if you split that way, the first part is pretty much exactly what did:plc is. Additionally, for complicated reasons like allowing recovery without opening major weakness, that's the one thing where having a centralized reference is important, so relying on the public https://plc.directory/ makes sense.
> In a distributed/p2p system with social interaction you need well defined identities that carries public keys. If you want to work offline, you actually need a full self-certified history of public key updates.
I don't understand how this is a problem. Isn't this already solved with keyservers and importing to a local keyring? My Linux distro has no problem keeping track of who is who and if they are trusted (not updating for a year or two would probably break things).
> so that you can backtrack to which pubkey(s) was active at the moment
I think GitHub solves this by simply checking at the time of the push and then never again (which is why you can change the keys without de-verifying older commits. Doesn't git's design yield blockchain-like assurance that nothing in the past has been modified?
---
https://web.plc.directory/ looks interesting, never heard of it.
Personally, I think signed commits should be the default. This is especially true in the age of AI where distinguishing humans from machines becomes harder every day. I would love for encrypted email/IM and sharing keys to be the norm for everyone but we're not there and may never be.
> I don't understand how this is a problem. Isn't this already solved with keyservers and importing to a local keyring? My Linux distro has no problem keeping track of who is who and if they are trusted (not updating for a year or two would probably break things).
There is different pieces that solve part of the problem (name/email from the git config, key servers for *some* users), but everything is disconnected, unstable, incomplete. Git-bug needs a stable identifier, the full self-certified pubkey log ... Those solutions are not good enough.
> Doesn't git's design yield blockchain-like assurance that nothing in the past has been modified?
It's not specific to git, but yes you get a chain of data blocks, content-addressed with signature support. That's what you want to build on, to have identities, roles, rules to enforce in a p2p system.
> Personally, I think signed commits should be the default. This is especially true in the age of AI where distinguishing humans from machines becomes harder every day. I would love for encrypted email/IM and sharing keys to be the norm for everyone but we're not there and may never be.
Agree! Note that if git-bug bring a solid identity primitive and publish pubkeys ... it can also carry the pubkeys that are *already* used to sign commits, publish them in the same public registry and verify code commits transparently, without relying on a third party to do so. Imho that's something missing in the current git model: if there is identities, there are segregated in third party systems like github. DIDs brings a lot to the table.
Ah, I see what you're getting at. Reminds me of Keybase. It's mostly just a messaging app now but there was some similar efforts made 10+ years ago:
https://keybase.io/blog/keybase-new-key-model
https://keybase.io/blog/encrypted-git-for-everyone
interesting stuff
[dead]
same question here. the other limitation i ran into immediately was only having two status types: open and closed
It's really hard (impossible?) to define a feature set that work for everyone. Every bug tracker is a bit different, and if you want to have everything you end with Jira, which I'm not sure is actually solving a problem.
However, git-bug's data model is designed in a way that you can add more "operations" on an entity (say: assign a bug) without every client having to implement it. You can also add your own entity type (pr, kanban, ...) the same way. Clients will just ignore that extra data and support what they want. This open the possibility for addons and so on.
For this specific case of the bug states, I want to add a config entity to configure that. You'd start with a reasonable default (open/close) but you could tune it for the needs of your project.
that sounds great and looking toward to it. is there an issue i can subscribe to?
There is https://github.com/git-bug/git-bug/issues/63, but I have plenty to do before that.
Git-bug looks amazing! Author of GitSocial here, would love to hear your opinion:
https://gitsocial.org/
Were you aware of git-bug when you created gitsocial? If so, which patterns did you reuse and which ones did you decide to diverge from? Or would you say the two projects embody fundamentally different visions?
Any thoughts to making this integrate alongside other systems that use git metadata to track changes?
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.
Stoked to see this.
I've long felt that something like this was the way but have never gotten around to working on it.
For your roadmap, it would help with collaborating and organizing to use the issue queue
Something like "scoped labels" https://youtu.be/7l7tnEva6I8?is=InYAVXHomobvbOjL
:thumbsup
Thanks for posting! I don't see any mention of beads, which can also store the database in Git (via Dolt). How does this compare to it?
this existed long before beads
Call for people who severely dislike Jira to chip in $1 each, that should give you some runway.
Is bug reporting in the future, or past? Is Git the future, or past?
It's deeply interesting to me that you decided to override git conflict-resolution (at least in the 90% of cases) in favor of CRDT conflict-resolution. That sort of decision is not uncommon but I was just kinda wondering -- did the CRDT idea come first or did you try a plain-text format for storing the bugs and you ran into certain common workflows where that wasn't ergonomic? (My first guess would maybe just be appending comments to the ticket -- so like if a ticket is a TOML file, you both append a comment at the end, Git immediately screams about what order should those two comments be in -- instead to make that ergonomic within Git's limitations you have to like, represent the comments as a directory tree with no inherent order and UUIDv4 names, and then Git will say "oh you both put blobs in that tree? that's fine. no conflicts," and then you have to order them by (declared-time, UUID) on the client side.)
What's not quite so clear from what I'm skimming is what you did to alleviate Git's postmodernism. What I mean is, Git just holds a bunch of refs like tags and branches and they all deliberately, inherently have equal valence -- this comes from the history of Linux being developed on an email list, there literally is not "one Linux", there is no truth about "what is the Linux v6.18 kernel" but rather there is a big family of v6.18 Linux kernels and anyone who wants to spin up a new one can literally just grab an existing v6.18 kernel and write a patch and bam, you have a new one. It's the blind sages and the elephant, every sage is correct about what the software is, within their limited ability to perceive what the software does. And this like perennially causes problems, right, people use Git for a modernist thing like CI/CD where at most companies "what's running in prod?" is one of those questions that we don't like to say "well it depends on your perspective, there is no one truth..."
Sorry for the long explainer -- I'm just aware that this is a very idiosyncratic way of phrasing the D in DVCS. But it's like, in concrete terms, do you have clients force themselves to declare a certain repo as their origin, and a certain ref on origin is the blessed Git-Bug ref that they have to push from and pull to? And like the add-on that you've crafted just doesn't let you branch the ticket list and all of that? Or -- the opposite -- do you go all-in on the postmodernism and say "no whether some strange-looking functionality is a 'bug', that is a fact that needs to be added to the holistic perspective of the project, and whether that bug is deemed fixed is a similar fact that, like, if you say you fixed the bug in `dev` it might still be not fixed in `uat` or `prod` -- so the bugs need to be stored in the repo that you're versioning anyways. And we use these CRDTs to give you a bird's eye consistent view of a Bunch of repos and all of their current statuses and all that." Or do you take a third direction that's neither purely modernist "this is the truth" nor purely postmodernist "every branch is true".
The choice to not use git merge handling was there from the beginning, the proper CRDT came a bit later when I understood more the problem and it's possible solutions. From a UX perspective, manually fixing merge conflict is the right thing for code, but it's a different story for social interactions: when the output you operate on is code, you want to precisely control that output. When the output is people understanding each other, you want to capture the intent. It's ok to, in rare case, be a little bit off in edge cases of the conflict resolution. What's not ok is forcing on the user to understand and deal with the problem.
Note that this very question is why some previous attempt at distributed bug tracker failed.
As for the postmodernism of git, I don't know ;-). I'm simply building on top of the lower level git database and leveraging the tools I have (like push/pull). Each bug is essentially its own namespace of operations that get moved around between repos. As with any CRDT, the state of that document get built from what is known at the time.
Your response here regarding CRDT was enlightening and thought provoking to me. Thank you. Really appreciate the distinction of "intent" especially in the context of human social interactions vs. code precision. Very interesting and insightful.
[dead]
[dead]
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
The webui supports markdown
its sad git-annotate was never really maintained
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...
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.
Thanks for reminding me of Fossil. I've been developing something locally and keeping track of things in a text file.
Fossil is very opinionated about some things, in particular, the inability to rewrite history, which makes it a non-option for some. So there's still a niche for Git-based distributed bug tracking.
Hits hard.
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
There is an alternative to auto-resolution or fixing low-level git merge conflicts. In my git forge Haxy, I am detecting conflicts in local-first metadata and allowing you to fix them in the UI. This is possible because I am not doing a line-based merge; the issues are stored as a data structure, so I can see what specific parts are in conflict. This allows a much nicer form of conflict resolution than conflict markers in a text file. I demoed this here: https://www.youtube.com/watch?v=kkGUARj5Wdw and here's the project: https://github.com/xit-vcs/haxy
Well written blog post! I enjoyed reading it.
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...
I'll fix that soon. I really wanted to avoid calling the git binary for security reason, but I have to admit that go-git is not robust enough in some cases. I'll have at least the option to use the git binary for push/pull, possibly as a default depending on how it goes.
You could always FFI to libgit2 rather than calling git
Glad to hear it! Thanks.
Isn't "show stopper" a bit dramatic? What is the big problem with an SSH agent? If security is a problem you should probably store your SSH keys on a HSM like a Nitrokey or Yubikey. In which case you need an agent.
The agent requirement is a symptom of a deeper potential issue: not using the system's ssh. Providing built-in as a fast-path option is fine, but ~/.ssh/config can do a lot of useful things, and providing an easy option to say "just use real ssh" lets people have their config just work.
Specifying identify files for specific hosts, using bastion hosts (ProxyJump), etc. For example, my laptop SSH config detects when I'm not on my university network or VPN and adds a ProxyJump through the department bastion host, but connects directly when I'm on the network. Configurations like that break when software makes too many assumptions about how ssh is configured.
oh wow, how can your ssh config change based on the network you're using?
ssh_config allows several ways to execute arbitrary shell commands, such as "Match exec" and "ProxyCommand". Specify a program that can detect networks and choose different connections. Then the config file itself wouldn't change.
you don't need an agent for hsm.
also, don't know a good security researcher who uses agents (some even use ssh config to limit which keys are even tried per domain)
ssh config hacks are also a must if you have, say, two or more identities to github.com for example.
hi - this is incorrect
I use a Yubikey for some of my keys, and I've never used an "agent", don't know how, and don't want to start, unless someone can give me a good reason to
ssh-keygen -t ed25519-sk
that's all you need to use a Yubikey with SSH
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.
I can somewhat understand your point about issues tied to branch, but have some remaining questions about how this working in practice:
- If I am on a branch where this issue exists and unaddressed, is it easy to find out if there is another branch where this issue has been addressed
- I am on a branch that does not have the issue reported, but know it's reported on another branch -- does that mean the issue doesn't exist on this branch? Is it on the reporter to correctly identify the root branch where the issue was first created? Do you have to somehow merge to make this work "right"?
I haven't actually tried in practice (across a team I mean), but:
> - If I am on a branch where this issue exists and unaddressed, is it easy to find out if there is another branch where this issue has been addressed
I do not have a solution for that.
> - I am on a branch that does not have the issue reported, but know it's reported on another branch -- does that mean the issue doesn't exist on this branch?
The idea was to create issues only on on a separate branch which is constantly merged into master. Then all branches downstream of master will get the issue when they rebase/pull.
Scenarios:
1. You're on branch `x/y/z`, you notice something that should be added to the issue tracker, you stash, switch to `/issues`, add the issue, push, switch back to `x/y/z` and pop.
2. An issue is to be created, the creator clones `/issues`, creates the issue, and pushes.
This way, all issues are on all branches, but only the branch dealing with an issue will update it.
The issue there was collaboration, one person would be on master and see no hint that a case was already being worked on (status, comments, etc all being different until the branch was merged). The other bullets, that put the information in different locations, were attempts to deal with this.
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.
Yeah, ticket is great! I liked it so much I ended up porting it to Python, which I find easier to read than awk/sh, and tweaking the command surface over dozens of iterations of trying to make the design more ‘self-explanatory’ for coding agents. https://github.com/a3lem/tiquette
(Excuse the vibe-coded README)
Anyway, even though I’m using it every day, I’m beginning to doubt the core idea of tracking hundreds of .md files in git. They get in the way of fuzzy file search, and if you keep closed tickets around in an archive directory, they just pile up endlessly.
Lately I’ve been considering breaking tickets out of VCS entirely or moving them to a dedicated repository just for ticket tracking.
Git bug looks like it might at least handle getting tickets out of the way
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.
Someone is taking lessons from fossil-scm.
Looks great by the way.
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...
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.
Fair enough, done!
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.
do one thing and do it well...
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.
Bugzilla has been using the term "bug" to track features for nearly 3 decades now. Doesn't seem to hamper them.
There’s also Fogbugz, Mantis Bug Tracker, etc.
Lack of a feature is a bug. After all, it's intended functionality that doesn't work!
It's also a denial of service, since the feature doesn't work yet, and thus should get assigned a CVE.
I once worked at a company where the chief architect created an actual bug in Jira, the entire text of which was, "X doesn't exist", X being the name of the product which took ~3 years to develop (and yes it was all tracked as dependencies of that one bug).
It’s a variation on the old Lisp technique of debugging the empty program. You start with () (a.k.a. nil), which doesn’t do what you want, so you debug it.
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.
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.
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?
They would be two different bugs (even with the same title). Someone would recognize the duplicate and close one. That would happen less as the time to sync decrease.
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.
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.
Trust me, I'm an engineer
That’s how we ended up on the brink of an AI dystopia…
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
Can this be used for more than just bugs? I feel like it can but the name is going to be limiting.
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’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.
Does it bridge to other repos with “git bug”?
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.
There is a certain appeal to not depending on more tools, and there is something elegant about the bug list traveling with revisions, if they are closed when the bug is fixed. So at any point you could go backwards and see known bugs at the time.
This also applies to certain project management flows and statuses.
Right, there are advantages of your defect list riding right along with the code repository itself. The history here is more interesting and keeping it connected to git allows portability options (maybe across network divides).
The resolved bug list in particular is an integral part of the source code history, because it explains the motivation behind the shape of that code.
From my own experience, debugging often means digging into git blame and finding the issues associated with those commits. Having that metadata directly in a repo, not tied to any specific platform, always in sync, is nice.
excellent! will definitely give this a try
See also: https://github.com/schacon/ticgit
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...
It's both really. If done well, the same local-first software can be a hosted solution and give you the "github" experience, or work fully locally, or anything in between with different topologies. If you work locally but care about some external sources, it's just a matter of notification, polling or transport. That can be done silently in the background.
Right but it's all this ceremony that kind of all begs the question - why git? What's the motivation behind using git to do all this if the repository (where the code lives) and the tickets (bugs in the product created by building the code), are naturally out of sync? eg in many cases a bug can't be closed until someone verifies it's fixed, which happens after merge. The point at which a bug is marked as verified is arbitrary with respect to the commits and code. It's just a radom point in time as far as git is concerned. To me there's no need for git to be involved in any way and a url to a ticket in a commit message is far superior in terms of tracking
The point of using git is to have a full software project (code, issues, ...) self-contained, without being trapped in or dependent on a SaaS, dead fast and working offline and integrating with all your tooling locally. All that with a single binary and git that virtually everyone use already.
Now what you are talking about seems to be about the lifecycle of a bug. With this model you can replicate the same behavior as on major bugtrackers, or also track some metadata (fix in commit xxx) and compute where the bug is "deployed". But that's a UX/social problem, not a technical one imho.
Sorry I just don't get it. It's a massive problem when a designer needs permission to force push to a repo to update a bug. These boundaries exist for a reason.
[dead]
see also: https://github.com/dspinellis/git-issue
[flagged]
[flagged]
[flagged]
[flagged]
[dead]
[dead]
[dead]
Looks like GitHub issue tracker is embedded in git itself. Interesting!
Who knows how many things GitHub does are actually embedded into git itself :)
Haha that’s true. hoping between my local git and the github issue board has always been so distracting. Think this is a good extension to git.
"you only need your git repository to have a bug tracker"
What if my git repo doesn't have a bug tracker?
It’s the difference between “Let’s eat, grandma” and “Let’s eat grandma”.
To have a bug tracker, you only need your git repository (and git-bug.)
well then you aren't using this project
Then your repo probably has bugs?