I use it for my project[0] to keep issues centralized with the repo, but I still use Github Discussions as a pseudo-bug tracker to let random users provide input. If it's a bug I add it to git-bug and sync it to Github issues for public viewing[1], but if you want use bug reports that's not really going to work.
[0] https://github.com/stryan/materia
[1] Ironically I got this workflow idea from ghostty and mise, both of which require users to submit bug reports as discussions first and only generate tagged issues once an actionable bug is determined.
This is incorrect.
$ git remote get-url origin
ssh://git@github.com/git-bug/git-bug.git
$ for n in bugs identities; do echo "${n} on the remote: " $(git ls-remote origin "refs/${n}/\*" | wc -l); done
bugs on the remote: 453
identities on the remote: 311
That said, yes, GitHub is still our source of truth, as our web application does not currently support "guest" access, and there are other platform features that our community uses that we do not currently have support for (e.g. discussions and pull requests). Big changes to the web ui are coming soon, which will help to unlock the ability to do these things.
I've also been in talks with the Radicle team about possible collaboration.
I didn't know git-bug doesn't support PRs yet. I think pull requests should be modeled as a kind of issue. It's an issue with some metadata that points to a commit (and besides the usual issue operations like add new comment or edit a comment, you also have the operation of editing the commit associated with the PR)
If git-bug gains suppport for Github discussions, it should also be able to import discussions from other places like a discourse forum. I think it would be kinda neat for projects that want to be self contained
> I've also been in talks with the Radicle team about possible collaboration.
This is awesome!!
It was born out of frustration and does just that. It is about to go v1 within days.
You don't want to start your Saturday morning declaring an _action struct, then filling the rest of the day staring at research papers about the current state of fast homomorphic encryption.
Does it have bidirectional tracking with Github? (if I create or comment on an issue in Github it will be reflected on epiq, and if I create on epiq, some bot will post it to Github). For me this is the key feature.
Also
> The system is designed to assure robustness and uses a number of techniques and design patterns to avoid merge conflicts.
I think the docs should describe this in detail.
Anyway maybe ask him to post this to HN some day!
An integration layer with github issues or other platforms is definitely not unthinkable.
V1 is about to be released in the coming days.
Thanks for the feedback. I will add a section about that in the readme!
[EDIT] - readme updated with section about event sourcing strategy
I was thinking about fossil in the context of agentic workflows the other day, after seeing a co-worker go all in on sort of shifting themselves to a TPM workflow, using a locally hosted kanban board (inspired by OpenAI's Symphony).
It'd make things easier to have everything shoved into the repo, other than that everything is now shoved in the same repo being handled by the barely constrained chaos monkey that is an LLM coding agent. Locking things down gets hard if it's got access to the whole thing there.
Technically the issues in Fossil are part of the repository, along with the wiki, code, forum, etc. They come along with every clone and (mostly) cannot be deleted from the historical record.
Items of Fossil that are merely "alongside" instead of actually in the repository include unversioned files, chatroom content, and users and access controls. (Not an exhaustive list.)