[HN Gopher] Git-bug: Distributed, offline-first bug tracker embe...
___________________________________________________________________
Git-bug: Distributed, offline-first bug tracker embedded in Git
Author : jyooru
Score : 319 points
Date : 2022-11-24 12:11 UTC (10 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| synergy20 wrote:
| This is a great project! git bug really should be a built-in
| subcommand for git.
| Izkata wrote:
| 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 wrote:
| 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 wrote:
| 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.
| teddyh wrote:
| There are a number of tools for distributed bug tracking:
|
| https://news.ycombinator.com/item?id=22833037
| smoyer wrote:
| BugsEverywhere seems to be defunct ... I actually switched to
| git-bug when trying to find an alternative.
| chriswarbo wrote:
| 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)
| pyrolistical wrote:
| 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.
| webstrand wrote:
| 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 wrote:
| It can already do that using a feature called "bridges"
| michaelmure wrote:
| ... 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...
| dang wrote:
| 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)
| goodpoint wrote:
| 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 wrote:
| That's not the only one. I'd appreciate a links or see also
| section in the readme with links to similar projects
| mrtesthah wrote:
| This looks awesome, but will switching branches or reverting
| commits in the repo affect the history of my git-bug issues?
| michaelmure wrote:
| 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).
| michaelmure wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| olvy0 wrote:
| Are there any plans to create a bridge to Azure issues? I
| searched for an open issue but couldn't find one.
| michaelmure wrote:
| 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.
| [deleted]
| modeless wrote:
| Very cool idea, was it inspired by Fossil? I would totally use
| this if it had a VSCode extension.
| michaelmure wrote:
| 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.
| tchaffee wrote:
| "Keep reading and _writing bugs_ " sounds a little off. Maybe
| change that to "writing bug reports"?
| javajosh wrote:
| Strong disagree. "Keep writing bugs" makes OP sound
| experienced, self-deprecating, and not self-serious. These
| are good things.
| Cthulhu_ wrote:
| Yeah, if there were no bugs, this application would lose
| its purpose, lmao.
| beezlewax wrote:
| 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 wrote:
| 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 :-)
| njt wrote:
| 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 wrote:
| 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".
| wankle wrote:
| 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 wrote:
| 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
| ThinkBeat wrote:
| 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.
| password4321 wrote:
| 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.
| zeckalpha wrote:
| You may want to review https://www.git-scm.com/about/trademark
|
| They have been stingy about projects with git in the name.
| M4v3R wrote:
| Have they? GitKraken & GitLens are pretty popular, commercial
| offerings, and they have been on the market for years.
|
| [0] https://www.gitkraken.com
| sebmellen wrote:
| Not to mention GitHub and GitLab either!
| [deleted]
| michaelmure wrote:
| 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
| xyzzy_plugh wrote:
| 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.
| Klasiaster wrote:
| 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.
| HighlandSpring wrote:
| tig-bug would be fun
| Jenk wrote:
| Quite fond of buggit :)
| evanb wrote:
| crickgit, mosgito, gnit, ...
| fishbacon wrote:
| 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.
| rswail wrote:
| 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 wrote:
| Before that we had ticgit but it stopped being developed
| gregwebs wrote:
| 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 wrote:
| It does not ... yet. Nothing prevent from making git-bug
| "branch aware", just someone writing the code for that.
| foreigner wrote:
| 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 wrote:
| +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.
| password4321 wrote:
| 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.
| wankle wrote:
| 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 wrote:
| The git log is a block chain.
| anonyme-honteux wrote:
| 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 wrote:
| 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 wrote:
| 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.
| topogios wrote:
| Perhaps there is a way to use tagging for "aliasing" a given
| issue?
| jedberg wrote:
| 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.
| jasfi wrote:
| I want it.
| smoyer wrote:
| 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 wrote:
| I agree, it seems self-defeating that the tool is
| independently distributed but offers bridges.
| michaelmure wrote:
| 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 wrote:
| 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.
| jarbus wrote:
| How do I remove git-bug from a repository?
| michaelmure wrote:
| 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.
| tionis wrote:
| 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 wrote:
| 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.
| throwaway892238 wrote:
| 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.
___________________________________________________________________
(page generated 2022-11-24 23:01 UTC)