- have the webui accept external auth (like github oauth) so that it can be a public portal and accept external interactions
- have the webui expose a git remote endpoint
- slightly rework identities (and likely root them in did:plc for pubkey distribution, the identity system from bluesky, without being an ATProto thing), which would allow to share identities between repos way more naturally
- extend to support pull-requests, possibly CI. That would make it a somewhat complete local-first forge that you can also self-host trivially
Also, while there is some attention ... I'm considering working on this full time. If you have some advice or opportunities on how I can support myself doing this, let me know!
> - have the webui accept external auth (like github oauth) so that it can be a public portal and accept external interactions
Have you looked into ForgeFed? It's a WIP plan for different Forgejo based forges to federate with each other. https://forgefed.org/
There's also this: https://indieauth.net/ though I haven't looked into it. I hope you could integrate one of these into your planned OAuth/account system!
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.
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.
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.
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.
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.
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
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.
No mention of Fossil, which works great and proves that the difficulty is in gathering dev interest.
It may be that the presence of Fossil as a mature option is enough to dissuade people from choosing/working on alternatives. I’m pleased to see git-bug slowly making progress though, maybe it will get there in time.
I looked into them. Most of them use some CRDT-ish machinery to merge concurrent ticket changes. (Fixing merge conflicts in tickets would be too disappointing.) As a CRDT person, I noticed that implementing CRDT merges in git itself mostly makes that machinery unnecessary. Then you can keep your tickets in plain Markdown, having CRDT merges for both code and metadata. I have it working here btw
My comment on there is about a surge in popularity of these over a decade ago, with a link to a previous comment about problems I remember them having that prevented them from being usable for most people ( https://news.ycombinator.com/item?id=47956979 ), because of their intended design rather than an implementation issue. For example bullet 3 was a problem in one, that another tried to solve with bullet 2.
I don't have time right now to look at this one to guess if these apply, but might be interesting/useful for someone else.
Other than the first bullet point in your list[1], my contribution in this regard addresses everything else.
Don't have a link handy but it's on github called "rotsit" (revenge of the something issue Tracker).
‐----‐------
[1] That's the entire point of having the issue tied to a branch: if an issue is marked resolved in the branch you are looking at, then its resolved in the branch you are looking at. Storing the issues independent of branch means you need to also store extra metadat about which branch it is broken on.
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.
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"?
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.
b4 maintainer and Director of LF IT Konstantin Ryabitsev demo-ed git-bug support in b4 and cgit (kernel.org fork) just this week at the Kernel Recipes conference:
I 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).
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.
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.
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 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.
FYI, this is my near-term roadmap:
Also, while there is some attention ... I'm considering working on this full time. If you have some advice or opportunities on how I can support myself doing this, let me know!Have you looked into ForgeFed? It's a WIP plan for different Forgejo based forges to federate with each other. https://forgefed.org/
There's also this: https://indieauth.net/ though I haven't looked into it. I hope you could integrate one of these into your planned OAuth/account system!
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.
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.
> I'm considering working on this full time. If you have some advice or opportunities on how I can support myself doing this, let me know!
You could consider an "enterprise" tier with a special subset of features and guaranteed support. But my experience tells me this will be really hard to substantially monetize, as the customer profile for that solution is probably not spending on software until they really need to (the saying goes: selling to developers is impossible, you need to sell to their boss). Maybe a donation model or a creator-centric thing could work out!
Don't sell to developers for their day jobs, but sell to developers for their hobbies.
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.
Something like "scoped labels" https://youtu.be/7l7tnEva6I8?is=InYAVXHomobvbOjL
:thumbsup
https://gitsocial.org/
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".
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.
My own slightly-similar thing (uses an explicit sequence, and signed objects in refs/): https://github.com/generalbusiness-ai/gitseq
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...
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.
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
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.
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.
https://github.com/google/git-appraise
I used git bug before but found I missed being able to edit tickets with a Markdown editor. So I built this: https://github.com/LoumTechnologies/ticketry
It may be that the presence of Fossil as a mature option is enough to dissuade people from choosing/working on alternatives. I’m pleased to see git-bug slowly making progress though, maybe it will get there in time.
I looked into them. Most of them use some CRDT-ish machinery to merge concurrent ticket changes. (Fixing merge conflicts in tickets would be too disappointing.) As a CRDT person, I noticed that implementing CRDT merges in git itself mostly makes that machinery unnecessary. Then you can keep your tickets in plain Markdown, having CRDT merges for both code and metadata. I have it working here btw
https://replicated.live/blog/meta
My comment on there is about a surge in popularity of these over a decade ago, with a link to a previous comment about problems I remember them having that prevented them from being usable for most people ( https://news.ycombinator.com/item?id=47956979 ), because of their intended design rather than an implementation issue. For example bullet 3 was a problem in one, that another tried to solve with bullet 2.
I don't have time right now to look at this one to guess if these apply, but might be interesting/useful for someone else.
Don't have a link handy but it's on github called "rotsit" (revenge of the something issue Tracker).
‐----‐------
[1] That's the entire point of having the issue tied to a branch: if an issue is marked resolved in the branch you are looking at, then its resolved in the branch you are looking at. Storing the issues independent of branch means you need to also store extra metadat about which branch it is broken on.
- 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"?
Looks great by the way.
https://b4.docs.kernel.org/en/latest/maintainer/bugs.html
https://git.kernel.org/pub/scm/utils/b4/b4.git/bugs/
https://kernel-recipes.org/en/2026/2026/09/22/live-blog-day-... (shameless plug)
It's human-readable, simple, and easy to work with. Basically there's no magic.
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.
This also applies to certain project management flows and statuses.
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.
Let’s hope the consultants and/PE don’t ruin this one.
Yeah yeah we don’t want a centralized service, but it’s the ideal use case for a centralized service.
That's the key feature to make a distributed bug tracker actually work in practice.
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.
Naming things is hard, but I can see that it might feel unnatural to use "git bug" to track features. Maybe that's totally okay because it does one thing - tracking bugs - very well, and the whole feature roadmap is living in another system/process anyways?
It's also a denial of service, since the feature doesn't work yet, and thus should get assigned a CVE.
Naming is hard, but I mostly didn't expect to reach that point :-)
Only once it gets fixed does it become a feature.
;)
Over the years I've noticed that "merging two designs into one" is a design smell. Nearly every technology we still use today has a very clear separation from other technologies, and is instead layered or composed to gain added functionality.
What if my git repo doesn't have a bug tracker?