I love seeing these projects make use of the wide-open namespace/references that git provides (outside of the basic `refs/heads` for git branches and `refs/tags` for tags). It looks like they store the data in the `bugs` namespace [1] (so refs/bugs/foo).

Other projects also make use of alternate namespaces. The oft-forgotten built-in "git notes" puts stuff in the `refs/notes/` namespace (specifically in `refs/notes/commits`). Gerrit uses the virtual `refs/for/` namespace for receiving commits for review, stores project config in `refs/meta/config`, and stores User data in `refs/users/` in a special repo [2]. I'm sure others do interesting things.

Alternate uses of git's DAG model are fascinating.

[1] https://github.com/git-bug/git-bug/blob/bd936650ccf44ca33cf9...

[2] https://gerrit-review.googlesource.com/Documentation/config-...

Git Bug screenshots:

- TUI recording (GIF): https://github.com/git-bug/git-bug/blob/master/doc/assets/tu...

- Web comments (PNG): https://github.com/git-bug/git-bug/blob/master/doc/assets/we...

- Web feed (PNG): https://github.com/git-bug/git-bug/blob/master/doc/assets/we...

While I like the idea of tool consolidation, bug trackers aren't just a tool for the engineers. At most companies I've worked at, the support team, designers, QA team, managers, etc. all use the bug tracker on a daily basis.

It sounds like you can "bridge" to somehow show the tracker outside Engineering, but then you're having to do work around the consolidation, and I'd imagine the result won't be as nice as a full-featured tracker designed for everyone to use.

But, I am curious to hear from someone who has actually used this thing.

Some screenshots would be nice. I found this one [0] of the TUI from 2018, but not much else.

[0] https://github.com/git-bug/git-bug/releases/tag/0.4.0

This is really neat! I know Microsoft would never integrate this into github, but what about integrating this other less vendor-lockin-ey scm platforms like forgejo or gitlab? It might be a much better fit then retrofitting activity-pub (current efforts in this space).

Imagine having repository issues seamlessly propagated and replicated across all your git mirrors.

It’s very weird seeing the coping / seething about a useful tool like this even in HN comments. People have really drunk the proverbial kool-aid / joined the dark side.

This is incredibly cool. I love seeing local first software starting to make a comeback. Github is becoming painful to use, even on a fast connection.

There's also https://github.com/dspinellis/git-issue which has much fewer dependencies.

I use this to note potential issues in my copy of the Git project. For outright bugs though I report them to the project.

Very cool project — love the offline-first, Git-native approach. One question:

How do you handle conflict resolution when multiple users modify the same issue or thread concurrently across remotes? Is it purely Git's merge mechanics, or do you apply any domain-specific heuristics?

This is so cool! Much more elaborated and closer to the real bug tracker than my own tiny project (https://github.com/jhspetersson/git-task) (oh, sorry for the shameless plug)

I've been yelling 'omg why doesnt someone build a ticketing system on the basis of git, having a separate 'root' (no-parent git commit that is at the bottom of a git tree; technically a git repo can have more than one), with most of the conversation happening in git commit form' - for YEARS.

This is wildly exciting.

Interesting that GPL3 was selected for this, while Git itself is GPL2 (these are incompatible licenses)

Funny.

Some days ago, on the Firefox mover to github topic, people were wondering if issue trackers should also be distributed.

Seems an interesting idea.

Love this kind of thing. Particularly in the age of AI being cheap and even on device there are even more reasons to have issues be near the code for easy access.

Similarly things like automatically promoting bugs into the test suite as SHOULD FAIL and so on

This looks cool and has the opportunity to replace my old and trusted todo.txt, but I couldn’t find how to create or resolve bugs. The CLI has features related to syncing but nothing about this, or did I miss something?

This really seems like an odd thing to make distributed. Do I now have to resolve conflicts in bug conversations? Am I going to find replies magically appearing before mine? The README doesn't even acknowledge that these difficulties might exist.

This sounds like it adds a ton of potential problems and solves some very minor ones:

* You can work offline. Great, but 90% of bug tracking is sending messages to other people so that's not particularly useful.

* You aren't tied to GitHub Issues or whatever. I guess that's good. Seems pretty marginal though.

Excited to try this. I like the look of that TUI.

Docs seem to miss instructions on how you add a bug! Did I miss it?

Might be interesting as a personal cross project todo tracker?

It's a little disappointing that BugsEverywhere/BE (https://github.com/aaiyer/bugseverywhere) never gained popularity.

I appreciate that tools like Git Bug are not tied to a single repo host but they are tied inherently to a single VCS (git). BE was not reliant on a specific VCS, and it's a *really* simple format on-disk too.