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...
- 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 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)
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 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.
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.
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.
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.
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)
They have been stingy about projects with git in the name.
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.
A less specific name might benefit the project? The part after the colon will explain the actual purpose.
But microsoft github effectively killed distributed bug trackers by refusing to support them.
[1] https://github.com/MichaelMure/git-bug/blob/master/doc/howto...
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.
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.
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 see there are bridges, but I got the impression i do not need one.
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
I'm considering adding a dedicated CLI command for that as it's a common concern.
