Git is too hard

How could you possibly not have learned anything by reading the wikipedia page for "torsor" that starts with the following?

In algebraic geometry, given a smooth algebraic group G, a G-torsor or a principal G-bundle P over a scheme X is a scheme (or even algebraic space) with an action of G that is locally trivial in the given Grothendieck topology in the sense that the base change Y × X P {\displaystyle Y\times _{X}P} Y\times _{X}P along "some" covering map Y → X {\displaystyle Y\to X} Y\to X is the trivial torsor Y × G → Y {\displaystyle Y\times G\to Y} Y\times G\to Y (G acts only on the second factor).[1] Equivalently, a G-torsor P on X is a principal homogeneous space for the group scheme G X = X × G {\displaystyle G_{X}=X\times G} G_{X}=X\times G (i.e., G X {\displaystyle G_{X}} G_{X} acts simply transitively on P {\displaystyle P} P.)

Look, there's even links to the sub-terms:

("algebraic group" article): In algebraic geometry, an algebraic group (or group variety) is a group that is an algebraic variety, such that the multiplication and inversion operations are given by regular maps on the variety.

("action" article): In algebraic geometry, an action of a group scheme is a generalization of a group action to a group scheme. Precisely, given a group S-scheme G, a left action of G on an S-scheme X is an S-morphism

("principal homogeneous space" article): In mathematics, a principal homogeneous space,[1] or torsor, for a group G is a homogeneous space X for G in which the stabilizer subgroup of every point is trivial. Equivalently, a principal homogeneous space for a group G is a non-empty set X on which G acts freely and transitively (meaning that, for any x, y in X, there exists a unique g in G such that x·g = y, where · denotes the (right) action of G on X). An analogous definition holds in other categories, where, for example,

Really, all you have to do is read the article carefully and follow the links to unknown terminology if you can't immediately intuit its meaning. However, it's only just basic category theory, really.

(yes, guys, /s).

> Imagine if git was lost and it had to be recreated, would it make sense to rebuild it exactly as it is now?

I find your argument to be "if things were different, wouldn't they be different?" which I don't find to be of much substance... but let me fancy your thought experiment:

Assuming the remembrance of the features/API was not lost there would be a worldwide effort to recreate it as soon as humanly possible due to the problems it solves better than any other SCM on the market. It's critical for global software engineering productivity. I have no doubt that a similar (if not exact copy) of git would be produced in very short time.

Let's take another piece of Torvald's software and ask the same question: if Linux disappeared overnight would things be done different? Well, yes... sure. but would things also be re-created near 1:1 due to the known success of the Kernel? Also yes, and as fast as humanly possible.

This 100%.

Git is simple, but not easy. I suspect this is by design. I vastly prefer simple tools over easy ones. Sure, you pay a little more up front in time and initial frustration, but ultimately you really grok the tools and life becomes easier.

Often, simplicity comes at the cost of being less user friendly.

It's harder to learn to drive a stick shift than an automatic, but the manual transmission is a simpler system than an automatic.

I think the "just Google the answer" mentality to overcoming Git's obvious shortcomings is really problematic. For example, we once had a junior developer run into a problem with Git and before asking anyone else they went off and found an answer on Stack Overflow that solved a similar but slightly different problem. They naively ran the suggested solution without reading the documentation and wound up deleting our entire remote repo. Fortunately we were able to recover everything...

For context, we used SVN successfully for years before that without ever running into a similar situation.

It matters a lot, because the use cases you've seen aren't the only ones that exist. In a tool so widespread as git, that is really not surprising.

By removing it's decentralised nature you've fundamentally built a different VCS. Perhaps SVN is acceptable for your use case, that's great! It's definitely not git though - basic expected use cases were lost as predicted at the start of this thread.