It’s my turn to do the obligatory mention of SourceHut :)
It is in alpha, but it is really promising. It is going all-in on email based git workflows (which was the original way of doing it before the github-style PR based workflow). I love the style and it’s minimalism - but don’t let that fool you, it has many features that you might not see at first glance. Imagine if cgit or gitweb was extended into a software forge with built-in support for email patches, mailing lists, issue tracking and CI.
If you are the type of person who attracts garbage issue tickets and often has to reject low-effort PRs on your projects, it forces a really good minimum entrance bar. Of course this comes at the cost of visibility of your projects, less networking effect, so I would suggest to not use it if you want easy visibility and 3rd party contribution on your projects.
No. The issue is that an assumption they make in the unsafe block does not actually always hold true. They changed the safe rust code to strenghten the (incorrect) assumption they made in the first place, because that is way easier than rearchitecting the unsafe part. I.e. if the unsafe part was somehow to be written safely, the mitigation they introduced now would not result in any difference in behaviour, it would be correct behaviour both before and after.
Tldr: the problem lies in the unsafe part