Dwarf Fortress’ graphical upgrade provides a new way into a wildly wonky game


michaelmure 12d
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...

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

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

teddyh 12d
There are a number of tools for distributed bug tracking:


webstrand 12d
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
rswail 12d
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.
synergy20 12d
This is a great project! git bug really should be a built-in subcommand for git.
mrtesthah 12d
This looks awesome, but will switching branches or reverting commits in the repo affect the history of my git-bug issues?
njt 12d
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.

foreigner 12d
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?

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


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

tionis 12d
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!
gregwebs 12d
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?
wankle 12d
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"?
jarbus 12d
How do I remove git-bug from a repository?
Izkata 11d
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)

dang 11d

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)

ThinkBeat 11d
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.

pyrolistical 11d
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.

throwaway892238 11d
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.

goodpoint 12d
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.