- 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.
> - 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!
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.
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 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.
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
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
A few months ago there was another of these posted, called Epiq: 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"?
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.
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:
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 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?
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 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).
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...
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.
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.
> - 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!
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.
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.
2 replies →
same question here. the other limitation i ran into immediately was only having two status types: open and closed
3 replies →
Stoked to see this.
I've long felt that something like this was the way but have never gotten around to working on it.
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.
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
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
Git-bug looks amazing! Author of GitSocial here, would love to hear your opinion:
https://gitsocial.org/
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.
1 reply →
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.
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.
2 replies →
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
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.
Can this be used for more than just bugs? I feel like it can but the name is going to be limiting.
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
its sad git-annotate was never really maintained
The webui supports markdown
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.
1 reply →
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
2 replies →
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...
A few months ago there was another of these posted, called Epiq: 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"?
1 reply →
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.
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.
Someone is taking lessons from fossil-scm.
Looks great by 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.
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.
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
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?
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 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).
See also: https://github.com/schacon/ticgit
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
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...
3 replies →
[dead]
see also: https://github.com/dspinellis/git-issue
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...
excellent! will definitely give this a try
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?
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 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.
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.
Their logo is a ladybug so everything works out in the end.
[flagged]
[flagged]
[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 :)
"you only need your git repository to have a bug tracker"
What if my git repo doesn't have a bug tracker?
Then your repo probably has bugs?
well then you aren't using this project