Top
Best
New

Posted by alentred 11 hours ago

Git-bug: Distributed, offline-first bug tracker embedded in Git(github.com)
274 points | 91 commentspage 2
Aissen 10 hours ago|
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)

mcepl 8 hours ago|
Wow! Was this sent upstream to cgit?
Aissen 8 hours ago||
A quick checks shows that it seems so, last month. No answer to the RFC yet, though.
bethekidyouwant 1 hour ago||
Does it bridge to other repos with “git bug”?
michaelastreiko 5 hours ago||
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.
inguz 4 hours ago||
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

dustfinger 8 hours ago||
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.

michaelmure 5 hours ago|
Fair enough, done!
zeroq 6 hours ago||
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.

rileymat2 6 hours ago|
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.

taftster 4 hours ago||
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).
promptsphereeee 4 hours ago||
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?
michaelmure 1 hour ago|
They would be two different bugs (even with the same title). Someone would recognize the duplicate and close one. That would happen less as the time to sync decrease.
sscaryterry 4 hours ago||
See also: https://github.com/schacon/ticgit
cush 8 hours ago||
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.

michaelmure 8 hours ago||
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.

cush 6 hours ago||
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...
michaelmure 5 hours ago||
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.
cush 5 hours ago||
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
michaelmure 5 hours ago||
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.

afaraha 5 hours ago||
[dead]
xyst 6 hours ago|
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.

michaelmure 5 hours ago|
Trust me, I'm an engineer
More comments...