4 ms·

why should people use this as opposed to https://github.com/git-bug/git-bug https://github.com/git-bug/git-bug?

khimaros 9mo ago
or if that's not similar enough, how about https://github.com/dspinellis/git-issue https://github.com/dspinellis/git-issue?
- wild_egg 9mo ago
  I'm not familiar with enough to say concretely. What's the dependency management experience like with those? That's really the core of my needs. On the surface though, those are both significantly heavier tools. At minimum, there's a learning or adaption curve. I had built workflows on top of Beads and making a drop-in replacement was easier than reworking all of them.
bbor 9mo ago
Just glancing at it: 1. That repo is based on 250+ .go files and stores stuff as git blobs, which is obviously a much more involved, collaboration-focused approach than this tool's 1 .sh file and human-readable markdown files. 2. `tk` seems to be built with agent usage in mind from the jump. I'm sure `git-bug` is perfectly usable, but it's clearly not a focus. 3. The two linux package managers listed for `git-bug` are for (drum-roll, please...) arch and nix. Of course the latter can be setup on every (?) distro, but speaking personally, I find that to be quite the red flag for a devtool! I'm sure it's a bright green ones for fans of those distros/mindsets, of course :)
- sudoforge 9mo ago
  hey, git-bug maintainer here! just to address the package management situation on linux: i currently use nixos, and previously ran arch linux for over a decade. the AUR package is community maintained, as is the nixpkgs package (i maintain it though, so the community doesn't really need to here). making installation simple on other, more commonly used distributions is a goal, but is less of a priority at the moment than feature work and bug fixes. we're very open to package maintainers on those distributions packaging git-bug, however :)

or if that's not similar enough, how about https://github.com/dspinellis/git-issue https://github.com/dspinellis/git-issue?

wild_egg 9mo ago
I'm not familiar with enough to say concretely. What's the dependency management experience like with those? That's really the core of my needs. On the surface though, those are both significantly heavier tools. At minimum, there's a learning or adaption curve. I had built workflows on top of Beads and making a drop-in replacement was easier than reworking all of them.

bbor 9mo ago

Just glancing at it: 1. That repo is based on 250+ .go files and stores stuff as git blobs, which is obviously a much more involved, collaboration-focused approach than this tool's 1 .sh file and human-readable markdown files. 2. `tk` seems to be built with agent usage in mind from the jump. I'm sure `git-bug` is perfectly usable, but it's clearly not a focus. 3. The two linux package managers listed for `git-bug` are for (drum-roll, please...) arch and nix. Of course the latter can be setup on every (?) distro, but speaking personally, I find that to be quite the red flag for a devtool! I'm sure it's a bright green ones for fans of those distros/mindsets, of course :)

sudoforge 9mo ago
hey, git-bug maintainer here! just to address the package management situation on linux: i currently use nixos, and previously ran arch linux for over a decade. the AUR package is community maintained, as is the nixpkgs package (i maintain it though, so the community doesn't really need to here). making installation simple on other, more commonly used distributions is a goal, but is less of a priority at the moment than feature work and bug fixes. we're very open to package maintainers on those distributions packaging git-bug, however :)