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

I personally hate how all these platforms like GitHub, GitLab, BitBucket, etc slapped a centralized relational database to manage issues, comments, merge requests, etc next to a distributed de-centralized system like Git.

I especially hate how they've integrated CI/CD into the Git platforms.

I loathe the fact that Microsoft has tied their AI to their Git platform.

I want my CI/CD to be agnostic. I want my AI to be agnostic. I want my issues, MRs, comments, etc to be decentralized and come along for the ride when I clone a repo.

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.

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.

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

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.

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)

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

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.

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)

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?

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?

It would be nice to see some screenshots of the tool. But it could be me not looking in the right place. I tried to find it among the documentation too.

Is there anybody using a sub directory in the fit repo with one markdown per ticket?

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?

I love this idea and any tool that reduces context switching out of the terminal (e.g. devdocs, fabric, tldr)

1. It may push the design boundaries, but a basic full text index with sqlite would be doable with the web interface. go-doc CLI does the same with the web UI. all indexing is client-side . The bug corpus is very small so indexing should be fast and consistent.

2. Tagging bugs with the observed and resolved git commit ID. that would improve bisect, merge, release management and changelog publication.

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.

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

[dead]

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.