There are two different things mentioned here, which I feel I need to clarify:

First, what you said about merging / creating a PR with broken tests. Absolutely you shouldn’t do that, because you should only merge once the feature is finished. If a test doesn’t work, then either it’s testing for the wrong aspect and should be rewritten, or the functionality doesn’t work 100% yet, so the feature isn’t ready to get merged. Even if you’re waiting for some other feature to get ready, because you need to integrate it or something, you’re still waiting, so the feature isn’t ready.

At the same time, the OP’s point about tests being supposed to fail at first isn’t too far off the mark either, because that’s precisely how TDD works. If you’re applying that philosophy (which I personally condone), then that’s exactly what you do: Write the test first, checking for expected behaviour (which is taken from the specification), which will obviously fail, and only then write the code implementing that behaviour.

But, even then, that failing test should be contained to e.g. the feature branch you’re working on, never going in a PR while it’s still failing.

Once that feature has been merged, then yes, the test should never fail again, because that indicates a new change having sabotaged some area of that feature. Even if the new feature is considered “essential” or “high priority” while the old feature is not, ignoring the failure is one of the easiest ways to build up technical debt, so you should damn well fix that now.

I’ve never used Mercurial, but a simple one based on the explanations and my experience with Git:

Locating the branch a commit originated from. If a git branch has been merged into (or rebased on) main or another branch, there’s no way to tell which commit came from which branch. But sometimes I’d really like that information to figure out what prompted a certain change. Without it, I need to use external tools like a ticketing system and hope the other developers added in the necessary information.

“History is written by the victors.” - what I immediately thought of.

If you want the magic explained, here’s a start: https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Welch

Huh, really? I thought there were slightly more women than men, but maybe that depends on the economies etc.

As for your second point, yes, exactly. They don’t reproduce. So it doesn’t matter if many men get one wife each, or if a few men get many wives each, the number of pregnancies won’t change, and the number of pregnancy-related deaths won’t change either. So (again), I don’t see how polygyny helps in this situation.

Edit: This first point was wrong, but the second point still stands.

Polygyny wouldn’t solve the aforementioned problem if we suppose that the birth rate of men and women is roughly the same. If one man has many wives, some of whom even die, then several other men won’t have any wives.

Hardly a surprise, since Windows 10 didn’t need new hardware to run. You could install it on anything.

There are pros to this:

If the person you blocked can’t see your posts, they can intuit that you’ve blocked them. Then, they might try and find you on other social media to harass you even further, or shift targets to someone else.

If they can see your posts, they have no idea they’ve been blocked, similar to Reddit’s shadow bans. This might make them think you’re just annoyed or rarely look at your DMs, making them invest even more time to uselessly try to contact you.

Of course, I can see the other side too, that you don’t want them to know about any (new) posts you’ve made; but it isn’t as one-sided as you seem to think it is.

Because you don’t need to have significant experience or rent a VPS in order to do that, and I can respect that. We don’t need to force FOSS developers to become proficient in everything.

What needs to happen is some kind of tool (ideally FOSS) that lets you spin up an actual forum with the same difficulty to set it up as Discord.