Git-bug: Distributed, offline-first bug tracker embedded in Git
Version 0.8 just got out. For the next one, I'll try to focus on making the codebase fully ready for multi-entities and introduce a Project Board. Later we can add support for code review!
If you are looking for how it works, you can have a look at the data model introduction.
git-bug is only pushed forward by volunteers so it's taking its time to fully grow, so I'll take the opportunity to welcome everyone to join the fun :-)
They have been stingy about projects with git in the name.
Probably my favorite is the built in TUI interface, that feature rocks.
I don’t recommend it for larger projects where you have lots of committers, the in-built feature of GitHub/GitLab probably works better for those types of setups. Where I think this tool really shines, and the perfect use case for it is with the dozens (or in my case, hundreds) of little repos you have where A) either you are the only committer, or B) the project is small (for some definition of that term), or C) if you want something setup quickly to track issues/features/milestones, you can always switch to something else later.
I wonder if we could use some sort of distributed naming scheme for this, similar to Blockchain DNS?
My primary concern would be the bus factor... the bridges to other issue trackers help alleviate that though.
I remember listing out 4-5 of these in the past when the topic has come up, but the only old one I can remember/find right now is https://github.com/dspinellis/git-issue
Edit - Found some more using duckduckgo instead of google:
* https://github.com/jashmenn/ditz (last update 12 years ago)
* https://bugseverywhere.org/ (I think this was the most popular at one point)
* https://github.com/marekjm/issue (this is separate from git-issue above)
* A blog post from 2012 that lists these and a few others (half the links are dead): http://www.cs.unb.ca/~bremner/blog/posts/git-issue-trackers/
From the blog post, the additional ones where the links still work:
* https://github.com/chilts/cil (last updated 11 years ago)
* http://syncwith.us/sd/ (last updated 6 years ago)
Show HN: Git-bug's reusable data model - https://news.ycombinator.com/item?id=31874192 - June 2022 (1 comment)
Show HN: Git-bug – Distributed bug tracker, or what to do when GitHub is down - https://news.ycombinator.com/item?id=22831604 - April 2020 (55 comments)
Show HN: Git-bug 0.4: performance, comment edition, GitHub importer - https://news.ycombinator.com/item?id=18315539 - Oct 2018 (2 comments)
Show HN: git-bug – Distributed bug tracker embedded in git - https://news.ycombinator.com/item?id=17782121 - Aug 2018 (94 comments)
I see there are bridges, but I got the impression i do not need one.
However, I have concerns how this tries to be the middle and bridge out to other systems. This makes me think about to git svn days and how it was the best svn client. I wonder would an alternative "git jira" be more successful, where instead of a bridge it becomes the "best jira client" that happens to use git cli.
Each bridge can be an arbitrary external executable that "speaks" a very simple protocol and schema (implemented in, say, JSON or YAML), communicating through environment variables, command-line options, and stdin/stout. A developer using any programming language can quickly create a new bridge without ever contacting your project. Not only does this allow a community to build and maintain plugins separate from your project, but companies can build private bridges for their own proprietary software.
An example is asdf's plugins (https://asdf-vm.com/plugins/create.html). There are many "officially supported" plugins, but making and using your own external plugin (in any language) takes about 10 minutes.
But microsoft github effectively killed distributed bug trackers by refusing to support them.