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 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.
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.
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.
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.
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.
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
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?
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.
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.
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".
They have been quite ok 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, 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.
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)
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.
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.
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.
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.
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"?
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.
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.