Hi, author here. Happy to answer questions.

Version 0.8 just got out[1]. 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[2].

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 :-)

[1]: https://github.com/MichaelMure/git-bug/releases/tag/v0.8.0

[2]: https://github.com/MichaelMure/git-bug/blob/master/doc/model...

You may want to review https://www.git-scm.com/about/trademark

They have been stingy about projects with git in the name.

There are a number of tools for distributed bug tracking:

https://news.ycombinator.com/item?id=22833037

I've wanted this ever since I learned that Fossil embedded its own bug tracker. Now I just need a way to ingest GitHub issues into this system

Wow, I've wanted this for ages and always thought it would be possible. Interesting to integrate it with things like version tags for tracking releases and things like bugs fixed and known problems in a release document.

This is a great project! git bug really should be a built-in subcommand for git.

This looks awesome, but will switching branches or reverting commits in the repo affect the history of my git-bug issues?

Happy user of git-bug for several years here, it’s a great tool, and the author is very receptive about bug fixes and adding new features.

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 understand why the bug IDs are hashes, but that's going to be pretty inconvenient for practical use. Yes I know we manage it with Git commit names, but bug IDs are printed and spoken much more than commits, e.g. when communicating with a test team, management, or even in release notes.

I wonder if we could use some sort of distributed naming scheme for this, similar to Blockchain DNS?

Unfortunately the official "past" link does not reveal that this project was first discussed 4 years ago (staying power!):

https://hn.algolia.com/?query=https%3A%2F%2Fgithub.com%2FMic...

My primary concern would be the bus factor... the bridges to other issue trackers help alleviate that though.

I also like the write up about its internal data structure. It really helped me understand how to build my own git based tools. So thanks for that!

Does this at all help connect a bug to the source control? For example, knowing that a bug is closed at a certain git revision?

Doesn't "is fully embedded in git: you only need your git repository to have a bug tracker" directly compete with and mostly nullify, "bridges to other bug trackers: use bridges to import and export to other trackers"?

How do I remove git-bug from a repository?

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)

Related:

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)

It says it does not add files. Where does it store all the info?

I see there are bridges, but I got the impression i do not need one.

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.

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.

https://www.bugseverywhere.org/ was doing this more than a decade ago

But microsoft github effectively killed distributed bug trackers by refusing to support them.