Git-bug: Distributed, offline-first bug tracker embedded in Git
github.comHi, 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...
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?
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.
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.
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.
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.
Very cool idea, was it inspired by Fossil? I would totally use this if it had a VSCode extension.
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.
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.
I haven't considered myself or git-bug worthy enough to bother him :-|
Are there any plans to create a bridge to Azure issues? I searched for an open issue but couldn't find one.
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.
"Keep reading and writing bugs" sounds a little off. Maybe change that to "writing bug reports"?
Strong disagree. "Keep writing bugs" makes OP sound experienced, self-deprecating, and not self-serious. These are good things.
Yeah, if there were no bugs, this application would lose its purpose, lmao.
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
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 :-)
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)
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
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.
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.
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.
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?
+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.
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.
Perhaps there is a way to use tagging for "aliasing" a given issue?
Someone said blockchain on HN, look out!
Only half-joking here: it probably wouldn't be too much work to incorporate hash cracking: https://news.ycombinator.com/item?id=33704297
But you can't use just auto-incrementing IDs in a distributed system.
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!!!
The git log is a block chain.
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.
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.
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.
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.
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".
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)
You may want to review https://www.git-scm.com/about/trademark
They have been stingy about projects with git in the name.
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.
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.
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.
Have they? GitKraken & GitLens are pretty popular, commercial offerings, and they have been on the market for years.
Not to mention GitHub and GitLab either!
Those all came before the crackdown
tig-bug would be fun
Quite fond of buggit :)
crickgit, mosgito, gnit, ...
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.
There are a number of tools for distributed bug tracking:
I personally use https://mrzv.org/software/artemis 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)
BugsEverywhere seems to be defunct ... I actually switched to git-bug when trying to find an alternative.
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.
That's not the only one. I'd appreciate a links or see also section in the readme with links to similar projects
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
It can already do that using a feature called "bridges"
... 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.
[1] https://github.com/MichaelMure/git-bug/blob/master/doc/howto...
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.
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.
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!
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.
This looks awesome, but will switching branches or reverting commits in the repo affect the history of my git-bug issues?
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).
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.
Before that we had ticgit but it stopped being developed
This is a great project! git bug really should be a built-in subcommand for git.
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.
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.
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"?
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
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?
It does not ... yet. Nothing prevent from making git-bug "branch aware", just someone writing the code for that.
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.
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.
- https://github.com/MichaelMure/git-bug/blob/master/doc/model...
- https://www.git-scm.com/book/en/v2/Git-Internals-Git-Objects
Thank you very much for helping me understand that.
How do I remove git-bug from a repository?
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.
I want it.
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)
I agree, it seems self-defeating that the tool is independently distributed but offers bridges.
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.
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.