Unfortunately, I don't think that's true.

Back then, when working with SVN, we had sites in various countries, with under provisioned VPNs between them. Loading up a single file history could take 15 minutes. I am not joking. Every single operation took ages, so really, any DVCS would have won in that situation, regardless of its approach to branches.

If the SVN server would sit in the same building then I guess the branching would have been the main selling point, but it was not the main selling point for us in that situation.

Heavy sarcasm here if it's not obvious. Of course I know why.

In comparison to SVN and other non-DVCs git did not need to continuously talk to the central server for history, "branch" creations, unlocking/locking files before changes, etc.

Linus wanted a DVCS, but they wanted centralization and licenses were expensive, so he decided to launch the git initiative where he provided scaffolding and the rest came from contributions.

I would like to comment on this, though:

> that only want simple, that finding the most blunt approach is the only way. It has felt tasteless. Anti-ambitious.

I am always aiming for simple. If it's simple, it's maintainable and can be easy to reason about. Doing that is hard work, though. I used to spend three iterations to achieve it: functions are simple, easy to reason about, properly named and composable.

It's the opposite of blunt, though, so it might be that you meant something else with the term "simple" :)

You can't just not show up for work and call in sick. Within the same day you have to call your doctor and explain the symptoms and they have to start the paperwork for the sick leave. Even if it is for a day.

For a cold or a cough you would not get sick leave, though.

A lot of those sick days are also childcare.

In the past, a human producing humanslop would get a serious talking to, but nowadays it's apparently a valid excuse "well, an LLM generated it". This approach is placing a huge burden on the reviewers, much more so than in the past.

Maybe it's possible to force the transliteration to use a different allocator and then you could use the one you wrote in C?

I mean we deal with daylight saving time all the time and I know it's not the same because the leap second affects UTC, not just local time zone, it's just that you are either dealing with monotonically increasing time like epoch, or you are dealing with "human" time and I found no distinction in the latter.

Is it "just" that leap seconds or delay seconds caused problems in epoch to utc conversion? Note the just in quotes, but did I just answer my own question? :)

My gaming preference is to go to an area as per game design, so the fact that I would be outmatched does not bother me and would prefer it that way. I do, however, understand why the game designers chose level scaling for what they wanted to achieve.