Git-bug: Distributed, offline-first bug tracker embedded in
380 points by jyooru 9 days ago | 79 comments
michaelmure 9 days ago [-]
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 :-)



fmajid 8 days ago [-]
Excellent idea! We need an interoperable format to break the monopoly of the forges like Github, but it will only gain traction if it is integrated in git itself the way it is in Fossil. Have you been in touch with the Git maintainers to see if they are open to the idea?
michaelmure 8 days ago [-]
I haven't but I'm not sure it's really necessary. What needs to happen first is a large enough usage of git-bug, or at least a large enough use case coverage. To do so, I think it needs:

- support for pull-requests

- support for external auth in the webUI, to make it work as a public frontend where anyone can browse and interact with bugs like any other forge

If that happens and people are convinced, I'd think that git-bug would become a natural companion for git. Then it's just a matter of packaging.

hosh 8 days ago [-]
I had been doodling ideas about a distributed forge. It would allow for a local-first environment. Updates can be broadcast on something lile ActivityPub, and some automatic way to pull from Githuv. Discussions can go there, though git-bug may be the better way to go.

My main goal is resiliency. A typical Elixir/Phoenix project, for example, will have some dependencies on github. If github or the internet goes down, or even disappears, there would be no way for us to rebuild that from source.

michaelmure 8 days ago [-]
What you are describing is exactly within git-bug's scope, and really not that far away! I'd love to make that happen, but unfortunately I have a demanding day job and rely on contributor's help.
hosh 8 days ago [-]
I have many time commitments as well. I would love yt set aside some time on this.

I’d implement this in Elixir though. I enjoy it, and Elixir has some good stuff for dealing with errors in a distributed system. Put some effort into release engineering.

This is part of my broader interest in a resilient internet. On the foundation of a decentralized forge is a way to do community-supported software. With a forge, the next step would be a way for communities to raise capital (bug bounties, features, kickstarter style), but without having to rely on big platforms to do so.

modeless 8 days ago [-]
Very cool idea, was it inspired by Fossil? I would totally use this if it had a VSCode extension.
michaelmure 8 days ago [-]
I was aware of fossil but never used it. It's not a new idea, it has been attempted many time before. Hopefully that one is the one reaching large usage :-) Regarding VSCode, the CLI commands are designed to be used for such integration. Hopefully someone makes it.
europeanguy 8 days ago [-]
Quick question: is it known what Linus thinks of the idea of having bug tracker in git? Saying that Linus has a track record of making his design decisions would be an understatement, so I would like to know what he thinks.
michaelmure 8 days ago [-]
I haven't considered myself or git-bug worthy enough to bother him :-|
olvy0 8 days ago [-]
Are there any plans to create a bridge to Azure issues? I searched for an open issue but couldn't find one.
michaelmure 8 days ago [-]
No plan but it's typically something that is brought by an eternal contributor as I need to focus on the core and I don't use those other tools. If you are up for the task, please do! A "good enough" bridge (config+import+export+tests) like the gitlab one is 1800 LOC.
8 days ago [-]
tchaffee 9 days ago [-]
"Keep reading and writing bugs" sounds a little off. Maybe change that to "writing bug reports"?
javajosh 9 days ago [-]
Strong disagree. "Keep writing bugs" makes OP sound experienced, self-deprecating, and not self-serious. These are good things.
Cthulhu_ 9 days ago [-]
Yeah, if there were no bugs, this application would lose its purpose, lmao.
beezlewax 9 days ago [-]
Yeh it is funny. Even the best will let a bug slip in every now and again. For most of us they're just part of the process
eichin 8 days ago [-]
I recall a quarterly review that fit "actually getting work done" into the fad-of-the-week by breaking it down into

* fix old bugs * write new bugs * ship bugs to customers

(mid 90s, "dash process" I think? it actually reflected good understanding of the methodology and helped kill it off :-)

Izkata 8 days ago [-]
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

Edit - Found some more using duckduckgo instead of google:

* (last update 12 years ago)

* (I think this was the most popular at one point)

* (this is separate from git-issue above)

* A blog post from 2012 that lists these and a few others (half the links are dead):

From the blog post, the additional ones where the links still work:

* (last updated 11 years ago)

* (last updated 6 years ago)

awinter-py 8 days ago [-]
more generally I think you're right about large teams needing a 'source of truth' that is complex (includes feedback from different layers of mgmt, includes user / real life bug feedback, capable of producing estimates, plays well with product design framework)

teams that have like anaplan and figma in their stack probably cannot use this

but for a team that would otherwise be using github issues for project mgmt, I don't think the in-git approach is awful

account42 8 days ago [-]
2015 was before Microsoft bought GitHub. There has been some movement to use other forges since then so I don't think this will have to fail to catch on just because it did before.
jlarocco 8 days ago [-]
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.
account42 8 days ago [-]
I think it's more that its a use case that you don't know yet you have. Like backups, the need for having an exit plan from a centralized bug tracker often only becomes apparent when it is already too late.
foreigner 8 days ago [-]
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?

fdye 8 days ago [-]
+1 to this commenter

Really cool idea, but I would second a shorter and sequential way of ID'ing bugs. Its common in QA flows to use the JIRA-like shorthand to discuss/assign tickets. <Proj alias>-<sequential num>. Proj-alias is usually like 3 letters/nums (project configurable). So like SEC-3640, QWE-123, etc. Human-readable/discussable bug ID is gonna be something desired. Hash could stay as an alternate for those with deeper GIT knowledge, but its gonna get verbose to discuss a ticket.

jedberg 8 days 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.

topogios 8 days ago [-]
Perhaps there is a way to use tagging for "aliasing" a given issue?
password4321 8 days ago [-]
Someone said blockchain on HN, look out!

Only half-joking here: it probably wouldn't be too much work to incorporate hash cracking:

But you can't use just auto-incrementing IDs in a distributed system.

wankle 8 days ago [-]
Blockchain is a terrific idea! Make it blockchain!! Not "block chain" like the git log but "blockchain" make all software use blockchain to make the world a better place for all of us!!!
bryanlarsen 8 days ago [-]
The git log is a block chain.
anonyme-honteux 8 days ago [-]
Nope the git log is a merkle tree. The blockchain is a merkle tree plus all the layers of overengineering you need to have a consensus algorithm. And usually you "need" a consensus algorithm mostly for ideological reasons. My view is that building trust is better than assuiming it can't or shouldn't exist.
eudoxus 8 days ago [-]
To be pedantic, both git logs and blockchains are actually Merkle DAGs or Hash Graphs, whichever you prefer. All Merkle Trees are Merkle DAGs but not all Merkle DAGs are Merkle Trees.
bryanlarsen 8 days ago [-]
Merkle tree is a technical term with a specific meaning.

Block chain is a fairly generic, badly misused term that I assert also covers the git log, which is actually a chain of cryptographic blocks where each block includes the hash of the previous. It even has a consensus algorithm. You can disagree, but your assertion is just an opinion in constrast to a misuse of the term Merkle tree.

njt 8 days ago [-]
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.

wankle 8 days ago [-]
This seems like the real niche for this tool, I have dozens of small repos on my systems at home and at work. I keep git repos in each of /bin, /etc, /root, ~/Documents and so on and this would be great for tracking issues or reminders, "hey don't forget I did change a config/doc/etc for XYZ reason".
dang 8 days ago [-]

Show HN: Git-bug's reusable data model - - June 2022 (1 comment)

Show HN: Git-bug – Distributed bug tracker, or what to do when GitHub is down - - April 2020 (55 comments)

Show HN: Git-bug 0.4: performance, comment edition, GitHub importer - - Oct 2018 (2 comments)

Show HN: git-bug – Distributed bug tracker embedded in git - - Aug 2018 (94 comments)

zeckalpha 9 days ago [-]
You may want to review

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

michaelmure 9 days ago [-]
They have been quite ok[1] about the trademark aspect, but they do have a point about the namespace grab. I'm actually at a point where I do consider opting out of the git integration[2], as the introduction of new entities (project board, pr ...) do make things confusing (or even conflicting) as a series of git sub-commands. I haven't came up with a really satisfying solution though.



Klasiaster 8 days ago [-]
Git plugins must have binaries that start with "git-" because that's how they become subcommands. If the binary is called "git-something" for that reason, and it's about the project git anyway, it kind of makes sense to use this as project name.
xyzzy_plugh 9 days ago [-]
This is a bit weird to me.

It's Git's own convention to add subcommands by placing a binary on the $PATH with the prefix `git-`. In this case, the subcommands becomes `git bug ...`.

How would one name this differently?

I tend to think this is more about commercial projects.

M4v3R 9 days ago [-]
Have they? GitKraken & GitLens are pretty popular, commercial offerings, and they have been on the market for years.


sebmellen 9 days ago [-]
Not to mention GitHub and GitLab either!
zeckalpha 7 days ago [-]
Those all came before the crackdown
8 days ago [-]
HighlandSpring 9 days ago [-]
tig-bug would be fun
Jenk 9 days ago [-]
Quite fond of buggit :)
evanb 8 days ago [-]
crickgit, mosgito, gnit, ...
fishbacon 9 days ago [-]
It also locks the scope to just git in the mind of the reader. Even if the scope broadens down the road.

A less specific name might benefit the project? The part after the colon will explain the actual purpose.

teddyh 9 days ago [-]
There are a number of tools for distributed bug tracking:

chriswarbo 8 days ago [-]
I personally use since it's very lightweight, agnostic about VCS, and stores issues in a standard format (maildir) with existing tooling for reading, writing and other processing (e.g. Emacs to read/write, and MHonArc to build into a Web site)
smoyer 8 days ago [-]
BugsEverywhere seems to be defunct ... I actually switched to git-bug when trying to find an alternative.
goodpoint 8 days ago [-] was doing this more than a decade ago

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

ptman 8 days ago [-]
That's not the only one. I'd appreciate a links or see also section in the readme with links to similar projects
webstrand 9 days ago [-]
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
tionis 9 days ago [-]
It can already do that using a feature called "bridges"
michaelmure 9 days ago [-]
... which are bidirectional and incremental, meaning that you can use git-bug as an offline and local copy for github[1], without having to convert everyone on the project to that tool.


throwaway892238 8 days ago [-]
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 ( There are many "officially supported" plugins, but making and using your own external plugin (in any language) takes about 10 minutes.

michaelmure 8 days ago [-]
Thank you for that idea, I haven't considered that. I'm not too sure about how feasible that is as right now bridges sit on a sort of framework for configurations, credentials, events ... that seems uneasy to break into a plugin protocol. We'll see where that goes.
tionis 8 days ago [-]
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!
michaelmure 8 days ago [-]
As mentioned in the release notes, the intent is really to have a reusable data structure in git capable of conflict resolution, plus all the tooling around that. So if you want to build a tool using the same techniques but outside of git-bug's scope, please consider using it as a library.
mrtesthah 9 days ago [-]
This looks awesome, but will switching branches or reverting commits in the repo affect the history of my git-bug issues?
michaelmure 9 days ago [-]
No, it's completely separated from your normal code and branches and doesn't pollute your development workflow. git-bug's data is stored in hidden branches (not in the way you think about branches though).
rswail 9 days ago [-]
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.
ilyt 9 days ago [-]
Before that we had ticgit but it stopped being developed
synergy20 8 days ago [-]
This is a great project! git bug really should be a built-in subcommand for git.
pyrolistical 8 days ago [-]
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.

password4321 8 days ago [-]
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.

wankle 8 days ago [-]
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"?
noveltyaccount 8 days ago [-]
Not at all, provides easy migration path, not even the whole team needs to migrate, or git-bug can be used as an offline copy of your primary bug repository
gregwebs 8 days ago [-]
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?
michaelmure 8 days ago [-]
It does not ... yet. Nothing prevent from making git-bug "branch aware", just someone writing the code for that.
ThinkBeat 8 days ago [-]
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.

mhio 8 days ago [-]
The info is in the git object store (.git/objects) similar to how git stores files.

The tool creates `Blob`s that are committed to a `Tree` same as git does for files.

These `Blob`s represent git_bug `Operation`s though, stored as JSON. Those operations combined make up a `Bug`. You could technically create a directory of files from what git_bug stores, as git does for regular repos, but each "file" is more like a row in a database than a file.



ThinkBeat 7 days ago [-]
Thank you very much for helping me understand that.
jarbus 8 days ago [-]
How do I remove git-bug from a repository?
michaelmure 8 days ago [-]
Delete .git/git-bug, .git/refs/bugs, .git/refs/identities, .git/refs/remote/*/bugs and .git/refs/remote/*/identities.

I'm considering adding a dedicated CLI command for that as it's a common concern.

jasfi 8 days ago [-]
I want it.
smoyer 8 days ago [-]
You can probably afford it! One thing that would be great is for projects to choose to adopt it without bridging (but I'm partial to decentralized behavior)
wankle 8 days ago [-]
I agree, it seems self-defeating that the tool is independently distributed but offers bridges.
michaelmure 8 days ago [-]
I disagree. Bridges are a great on-ramp, as you can individually choose to adopt the tool without having everyone on the project (let alone users) agree to switch. It breaks the network effect. It's also a much needed migration path as you don't want to lose your project history. As a bonus, it's also a way to have backups, even if you keep using your centralized forge.
smoyer 8 days ago [-]
You know I'm a zealot! ... Imagine the day when that network effect is flipped and new projects start with git-bug and spin up a webui to allow the decentralized stragglers to participate.

In the interim, it would be cool if projects on GitHub (e.g.) would run the bridges as an action to keep GitHub issues synced with git-bug commits right in the repository.

EDIT: Of course the above implies we all learn to use git without a central serve too ... Something I'm not ready for either.