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

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

	▲	wild_egg 3 days ago \| parent [-]
		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 3 days ago | parent | prev [-]

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 3 days ago \| parent [-]
		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 :)