Git-bug: Distributed, offline-first bug tracker embedded in Git

Around 2010-2015 there were a whole bunch of these distributed git bugtrackers and none of them took off. Most are completely dead. IIRC one of the biggest problems was its feature: issue state being distributed as it is, it was very easy for developers to end up with issues having different states/comments, and depending on the implementation even differed across local branches. But also in a work environment there was no place for project managers to view/create/update issues.

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)

It doesn't even have to be that complicated. How many bugs and contributors can a project have?

Add a bug_id_lockfile where you claim a namespace that starts with a letter, and if you sync up and someone has already claimed that namespace, you have to change and rename your bugs. The time of the checkin determines who gets it. There might be a couple bugs you have to rename, if you don't sync up right away.

So my bugs would start with A, yours with B, and so on. Once you get to 26 contributors you do two letters, etc.

For applications where there may be many arbitrary "bridges" (aka integrations, plugins) to integrate with external software, a great way to scale support for bridges is to make them completely separate projects in external repositories.

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.

I like this concept, especially if you use a centralized host like github/gitlab, then a hosted webui makes sense for non-devs to be able to view/edit issues.

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.

Yeah, I agree. I'm not against making it a built-in, but it seems to cater to a tiny usecase that I don't have. Maybe it's more people than I know, though.