> To the "Git is distributed!" crowd: the issue isn't Git, it's the infrastructure we rely on around it: issues, PRs, Actions, etc.
A suggestion: use git-bug https://github.com/git-bug/git-bug in addition to migrating to another forge like Codeberg. It saves issues, PRs etc in git itself (not on a branch - on a specially crafted ref). It offers two way sync with a lot of providers.
Other VCSes like fossil store issues alongside the repo. I think it's appropriate because in a sense, issues are part of what gives meaning to the code (like documentation)
Granted I'm biased (being the brother of the developer), but there is also epiq, which is still more bleeding edge but from what I understand has a much more powerful UI story (basically an issue board in the terminal, being a TUI app):
https://github.com/ljtn/epiq
git-bug is great but it doesn't handle PRs nor does it have a method for users without commit rights to submit bugs to the project. I know they're working on the latter (something with the web UI?) but until then you still need some kind of public infra for issue management if you want the general public to be able to submit issues.
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.
Maybe Mitchell will pull a Linus and, out of frustration, take a weekend off to write the distributed infrastructure for issues, PRs, actions, etc. around git.
https://radicle.dev/
The most important part of Linus' project was day -1, when he sliced off all the chunks of work that depend on solving open research problems.
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.
It was 10 days, but that's fine too.
> Other VCSes like fossil store issues alongside the repo. I think it's appropriate because in a sense, issues are part of what gives meaning to the code (like documentation)
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.
> Other VCSes like fossil store issues alongside the repo.
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.)
Even if you only used raw git with GitHub, it still wouldn't work. Pushing changes from my laptop would fail for hours when their SSO would break.
It's definitely time to turn these loose web features into a real program. I don't understand the desire to clone github as a website. It's demonstrably 10,000x more work to maintain github.com than a "github" command.
I didn't know of this, that special ref mechanism sounds really cool! Thanks for the protip
We've had trouble with git and repo's that have used non standard refs. It's all fine and fancy until we wanted to use some tooling that works with git, except it wouldn't see our unusual refs, and because they were non standard they were effectively hidden unless you knew they were there. So the migration work (almost) silently lost 10+ years of old work that was hiding away under those non standard refs.