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?

Isn't everything nowadays a bug?

Only once it gets fixed does it become 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 :-)

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 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"?

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...

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

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.

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

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!

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.

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?

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?

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.

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?

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

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

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

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

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.

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...

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?

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.

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.