9 ms·

Git-bug: Distributed, offline-first bug tracker embedded in Git

380 points by jyooru 4y ago

webstrand 4y 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 4y ago
  It can already do that using a feature called "bridges"
  - michaelmure 4y 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. [1] https://github.com/MichaelMure/git-bug/blob/master/doc/howto-github.md https://github.com/MichaelMure/git-bug/blob/master/doc/howto...
michaelmure 4y 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 :-) [1]: https://github.com/MichaelMure/git-bug/releases/tag/v0.8.0 https://github.com/MichaelMure/git-bug/releases/tag/v0.8.0 [2]: https://github.com/MichaelMure/git-bug/blob/master/doc/model.md https://github.com/MichaelMure/git-bug/blob/master/doc/model...
- europeanguy 4y 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 4y ago
    I haven't considered myself or git-bug worthy enough to bother him :-|
- tchaffee 4y ago
  "Keep reading and writing bugs" sounds a little off. Maybe change that to "writing bug reports"?
  - javajosh 4y ago
    Strong disagree. "Keep writing bugs" makes OP sound experienced, self-deprecating, and not self-serious. These are good things.
    - beezlewax 4y 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
    - Cthulhu_ 4y ago
      Yeah, if there were no bugs, this application would lose its purpose, lmao.
    - eichin 4y 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 :-)
- olvy0 4y ago
  Are there any plans to create a bridge to Azure issues? I searched for an open issue but couldn't find one.
  - deleted 4y ago
    [deleted]
  - michaelmure 4y 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.
- fmajid 4y 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 4y 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 4y 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 4y 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 4y 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 4y ago
  Very cool idea, was it inspired by Fossil? I would totally use this if it had a VSCode extension.
  - michaelmure 4y 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.
zeckalpha 4y ago
You may want to review https://www.git-scm.com/about/trademark https://www.git-scm.com/about/trademark They have been stingy about projects with git in the name.
- HighlandSpring 4y ago
  tig-bug would be fun
  - Jenk 4y ago
    Quite fond of buggit :)
    - evanb 4y ago
      crickgit, mosgito, gnit, ...
- fishbacon 4y 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.
- M4v3R 4y ago
  Have they? GitKraken & GitLens are pretty popular, commercial offerings, and they have been on the market for years. [0] https://www.gitkraken.com https://www.gitkraken.com
  - sebmellen 4y ago
    Not to mention GitHub and GitLab either!
    - zeckalpha 4y ago
      Those all came before the crackdown
rswail 4y 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 4y ago
  Before that we had ticgit but it stopped being developed
teddyh 4y ago
There are a number of tools for distributed bug tracking: https://news.ycombinator.com/item?id=22833037 https://news.ycombinator.com/item?id=22833037
- chriswarbo 4y ago
  I personally use https://mrzv.org/software/artemis 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)
- smoyer 4y ago
  BugsEverywhere seems to be defunct ... I actually switched to git-bug when trying to find an alternative.
mrtesthah 4y ago
This looks awesome, but will switching branches or reverting commits in the repo affect the history of my git-bug issues?
- michaelmure 4y 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).
synergy20 4y ago
This is a great project! git bug really should be a built-in subcommand for git.
jasfi 4y ago
I want it.
- smoyer 4y 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 4y ago
    I agree, it seems self-defeating that the tool is independently distributed but offers bridges.
    - michaelmure 4y 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 4y 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.
tionis 4y 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 4y 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.
foreigner 4y 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?
- password4321 4y ago
  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 https://news.ycombinator.com/item?id=33704297 But you can't use just auto-incrementing IDs in a distributed system.
- topogios 4y ago
  Perhaps there is a way to use tagging for "aliasing" a given issue?
- wankle 4y 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 4y ago
    The git log is a block chain.
    - anonyme-honteux 4y 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.
goodpoint 4y ago
https://www.bugseverywhere.org/ 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.
- ptman 4y ago
  That's not the only one. I'd appreciate a links or see also section in the readme with links to similar projects
njt 4y 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 4y 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".
password4321 4y ago
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%2FMichaelMure%2Fgit-bug 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.
wankle 4y 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 4y 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 4y 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 4y ago
  It does not ... yet. Nothing prevent from making git-bug "branch aware", just someone writing the code for that.
jarbus 4y ago
How do I remove git-bug from a repository?
- michaelmure 4y 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.
Izkata 4y 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 https://github.com/dspinellis/git-issue https://github.com/dspinellis/git-issue Edit - Found some more using duckduckgo instead of google: * https://github.com/jashmenn/ditz https://github.com/jashmenn/ditz (last update 12 years ago) * https://bugseverywhere.org/ https://bugseverywhere.org/ (I think this was the most popular at one point) * https://github.com/marekjm/issue 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/ 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 https://github.com/chilts/cil (last updated 11 years ago) * http://syncwith.us/sd/ http://syncwith.us/sd/ (last updated 6 years ago)
- account42 4y 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.
- awinter-py 4y 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
- jlarocco 4y 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.
dang 4y ago
Related: Show HN: Git-bug's reusable data model - https://news.ycombinator.com/item?id=31874192 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 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 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 https://news.ycombinator.com/item?id=17782121 - Aug 2018 (94 comments)
throwaway892238 4y 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 (https://asdf-vm.com/plugins/create.html 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.
- michaelmure 4y 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.
pyrolistical 4y 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.
ThinkBeat 4y 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 4y 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. - https://github.com/MichaelMure/git-bug/blob/master/doc/model.md https://github.com/MichaelMure/git-bug/blob/master/doc/model... - https://www.git-scm.com/book/en/v2/Git-Internals-Git-Objects https://www.git-scm.com/book/en/v2/Git-Internals-Git-Objects
  - ThinkBeat 4y ago
    Thank you very much for helping me understand that.

380 points by jyooru 4y 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 4y ago
It can already do that using a feature called "bridges"
- michaelmure 4y 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. [1] https://github.com/MichaelMure/git-bug/blob/master/doc/howto-github.md https://github.com/MichaelMure/git-bug/blob/master/doc/howto...

michaelmure 4y 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 :-) [1]: https://github.com/MichaelMure/git-bug/releases/tag/v0.8.0 https://github.com/MichaelMure/git-bug/releases/tag/v0.8.0 [2]: https://github.com/MichaelMure/git-bug/blob/master/doc/model.md https://github.com/MichaelMure/git-bug/blob/master/doc/model...

europeanguy 4y 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 4y ago
  I haven't considered myself or git-bug worthy enough to bother him :-|
tchaffee 4y ago
"Keep reading and writing bugs" sounds a little off. Maybe change that to "writing bug reports"?
- javajosh 4y ago
  Strong disagree. "Keep writing bugs" makes OP sound experienced, self-deprecating, and not self-serious. These are good things.
  - beezlewax 4y 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
  - Cthulhu_ 4y ago
    Yeah, if there were no bugs, this application would lose its purpose, lmao.
  - eichin 4y 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 :-)
olvy0 4y ago
Are there any plans to create a bridge to Azure issues? I searched for an open issue but couldn't find one.
- deleted 4y ago
  [deleted]
- michaelmure 4y 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.
fmajid 4y 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 4y 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 4y 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 4y 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 4y 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 4y ago
Very cool idea, was it inspired by Fossil? I would totally use this if it had a VSCode extension.
- michaelmure 4y 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.

zeckalpha 4y ago

You may want to review https://www.git-scm.com/about/trademark https://www.git-scm.com/about/trademark They have been stingy about projects with git in the name.

HighlandSpring 4y ago
tig-bug would be fun
- Jenk 4y ago
  Quite fond of buggit :)
  - evanb 4y ago
    crickgit, mosgito, gnit, ...
fishbacon 4y 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.
M4v3R 4y ago
Have they? GitKraken & GitLens are pretty popular, commercial offerings, and they have been on the market for years. [0] https://www.gitkraken.com https://www.gitkraken.com
- sebmellen 4y ago
  Not to mention GitHub and GitLab either!
  - zeckalpha 4y ago
    Those all came before the crackdown

rswail 4y 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 4y ago
Before that we had ticgit but it stopped being developed

teddyh 4y ago

There are a number of tools for distributed bug tracking: https://news.ycombinator.com/item?id=22833037 https://news.ycombinator.com/item?id=22833037

chriswarbo 4y ago
I personally use https://mrzv.org/software/artemis 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)
smoyer 4y ago
BugsEverywhere seems to be defunct ... I actually switched to git-bug when trying to find an alternative.

mrtesthah 4y ago

This looks awesome, but will switching branches or reverting commits in the repo affect the history of my git-bug issues?

michaelmure 4y 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).

synergy20 4y ago

This is a great project! git bug really should be a built-in subcommand for git.

jasfi 4y ago

I want it.

smoyer 4y 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 4y ago
  I agree, it seems self-defeating that the tool is independently distributed but offers bridges.
  - michaelmure 4y 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 4y 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.

tionis 4y 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 4y 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.

foreigner 4y 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?

password4321 4y ago
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 https://news.ycombinator.com/item?id=33704297 But you can't use just auto-incrementing IDs in a distributed system.
topogios 4y ago
Perhaps there is a way to use tagging for "aliasing" a given issue?
wankle 4y 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 4y ago
  The git log is a block chain.
  - anonyme-honteux 4y 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.

goodpoint 4y ago

https://www.bugseverywhere.org/ 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.

ptman 4y ago
That's not the only one. I'd appreciate a links or see also section in the readme with links to similar projects

njt 4y 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 4y 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".

password4321 4y ago

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%2FMichaelMure%2Fgit-bug 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.

wankle 4y 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 4y 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 4y 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 4y ago
It does not ... yet. Nothing prevent from making git-bug "branch aware", just someone writing the code for that.

jarbus 4y ago

How do I remove git-bug from a repository?

michaelmure 4y 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.

Izkata 4y 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 https://github.com/dspinellis/git-issue https://github.com/dspinellis/git-issue Edit - Found some more using duckduckgo instead of google: * https://github.com/jashmenn/ditz https://github.com/jashmenn/ditz (last update 12 years ago) * https://bugseverywhere.org/ https://bugseverywhere.org/ (I think this was the most popular at one point) * https://github.com/marekjm/issue 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/ 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 https://github.com/chilts/cil (last updated 11 years ago) * http://syncwith.us/sd/ http://syncwith.us/sd/ (last updated 6 years ago)

account42 4y 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.
awinter-py 4y 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
jlarocco 4y 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.

dang 4y ago

Related: Show HN: Git-bug's reusable data model - https://news.ycombinator.com/item?id=31874192 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 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 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 https://news.ycombinator.com/item?id=17782121 - Aug 2018 (94 comments)

throwaway892238 4y 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 (https://asdf-vm.com/plugins/create.html 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.

michaelmure 4y 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.

pyrolistical 4y 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.

ThinkBeat 4y 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 4y 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. - https://github.com/MichaelMure/git-bug/blob/master/doc/model.md https://github.com/MichaelMure/git-bug/blob/master/doc/model... - https://www.git-scm.com/book/en/v2/Git-Internals-Git-Objects https://www.git-scm.com/book/en/v2/Git-Internals-Git-Objects
- ThinkBeat 4y ago
  Thank you very much for helping me understand that.