git is decentralised. github issues & merge-requests are not.

Say you have a project hosted on github, pretend github has been purchased by a scary-company, you might imagine you could move your repository elsewhere. You can, but suddenly your issues need to be imported/migrated too.

If you had a fossil-host instead? You could migrate your repository and your issues all at once, and nobody would care.

(Disclaimer: I use github for public projects, and self-hosted gitbucket for private stuff. I don't care that github has changed ownership.)

I don't use fossil, but I have fantasized about keeping docs and issues in version control alongside the code.

My organization has churned through several different issue trackers in the last few years. And a lot of that old data is just gone; project owners never bothered pulling Fogbugz tickets into Phabricator or never pulled Phabricator tasks into JIRA. If we had issue tracking that lived alongside the source code in version control, then the underlying data would last as long as the code did.

Shouldn't? Hasn't been.

If you actually read through the discussion on the mailing list, what Zed did (as I recall it from when this was news years ago) was screw up an operation, run into a bug, panic and start hammering on the repo to try to undo the problem that arose, and basically destroy the repo's ability to roll back what he did.