michaelmure 16 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 :-)

[1]: https://github.com/MichaelMure/git-bug/releases/tag/v0.8.0

[2]: https://github.com/MichaelMure/git-bug/blob/master/doc/model...

  • fmajid 15 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 15 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 15 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 15 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 15 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 15 days ago

    Very cool idea, was it inspired by Fossil? I would totally use this if it had a VSCode extension.

    • michaelmure 15 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 15 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 15 days ago

      I haven't considered myself or git-bug worthy enough to bother him :-|

  • olvy0 15 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 15 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.

  • tchaffee 16 days ago

    "Keep reading and writing bugs" sounds a little off. Maybe change that to "writing bug reports"?

    • javajosh 16 days ago

      Strong disagree. "Keep writing bugs" makes OP sound experienced, self-deprecating, and not self-serious. These are good things.

      • Cthulhu_ 15 days ago

        Yeah, if there were no bugs, this application would lose its purpose, lmao.

      • beezlewax 16 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 15 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 15 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 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)

  • awinter-py 15 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 15 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 15 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 15 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 15 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 15 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 15 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 15 days ago

    Perhaps there is a way to use tagging for "aliasing" a given issue?

  • wankle 15 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 15 days ago

      The git log is a block chain.

      • anonyme-honteux 15 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 15 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 15 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 15 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 15 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 15 days ago

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)

zeckalpha 16 days ago

You may want to review https://www.git-scm.com/about/trademark

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

  • michaelmure 16 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.

    [1]: https://marc.info/?l=git&m=153457109619678&w=2

    [2]: https://github.com/MichaelMure/git-bug/issues/530

  • Klasiaster 15 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 16 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 16 days ago

    Have they? GitKraken & GitLens are pretty popular, commercial offerings, and they have been on the market for years.

    [0] https://www.gitkraken.com

    • sebmellen 16 days ago

      Not to mention GitHub and GitLab either!

      • zeckalpha 14 days ago

        Those all came before the crackdown

  • HighlandSpring 16 days ago

    tig-bug would be fun

    • Jenk 16 days ago

      Quite fond of buggit :)

      • evanb 15 days ago

        crickgit, mosgito, gnit, ...

  • fishbacon 16 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 16 days ago

There are a number of tools for distributed bug tracking:

https://news.ycombinator.com/item?id=22833037

  • chriswarbo 15 days ago

    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)

  • smoyer 15 days ago

    BugsEverywhere seems to be defunct ... I actually switched to git-bug when trying to find an alternative.

goodpoint 15 days ago

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 15 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 16 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

throwaway892238 15 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 (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 15 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 15 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 15 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 15 days ago

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

  • michaelmure 15 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 16 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 16 days ago

    Before that we had ticgit but it stopped being developed

synergy20 15 days ago

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

pyrolistical 15 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.

wankle 15 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 15 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 15 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 15 days ago

    It does not ... yet. Nothing prevent from making git-bug "branch aware", just someone writing the code for that.

ThinkBeat 15 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.

jarbus 15 days ago

How do I remove git-bug from a repository?

  • michaelmure 15 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 15 days ago

I want it.

  • smoyer 15 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 15 days ago

      I agree, it seems self-defeating that the tool is independently distributed but offers bridges.

      • michaelmure 15 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 15 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.