Did you mean inherent complexity instead of incidental complexity?

I think the inherently complex things in git are (1) the content-accessible object store, snapshots, plus the merkel tree approach to keeping track of commits and parenthood, (2) merges, rebases, and resolving conflicts between two different changes with a common ancestor, (3) possibly syncing commits between different remotes, although I think Git's approach adds accidental complexity to the problem as well.

Everything else is a question of the user interface: how you choose to show a commit, how you choose to update the project files, how you choose to let people create new commits, etc. And I think the Git CLI is a poor user interface in a lot of places. There are a lot of features which are really powerful but difficult to use, whereas actually they could be just as powerful but far more intuitive to use.

In fairness, this is no slight to the Git developers - they are improving a lot of that interface all of the time. And finding a simpler interface is often a lot more hard work than finding the complicated interface, and I don't think I would have figured out how to create something like jj until I'd seen it before.

I think you need to setup something like magit, tig, and maybe lazy git, to truly see the power of git. Most people don't do version control other than snapshotting things every once in a while. They might as well use git inside cron.

A patch is an idea to take the code from a state to another state. It contains both the mechanical work, the intent, and extra metadata. It's essential when doing distributed development work over a single code base. A git repo is a node and it lets you accept and produce new message to the other nodes.

If you care about the state of the canonical repo, you want every step to be able to compile/build/be verified. So that means accepting good patches from everyone else.

But the work of producing new patches can be messy. But you still need to track each steps, branch off to do experiments, catchup with new updates to the foundational model of the code,...

The design of how git store information makes all those operations simple while giving you the maximum control over them. But there's one mechanism that is kinda the bane of every novice: diffing and patching. Because git doesn't store the file deltas. It stores the changed files. Diffing is the interface for inspecting the changes and patching is how those changes are propagated to files.

The default diff mechanism relies heavily on lines. Which suits most programming languages as a line is often the unit of intent. Conflict occurs when git detect that two diffs is trying to alter the same section of the files. It's actually a solution mechanism instead of a problem as most novices see it.

But I don't blame them as a lot of novice don't have experience with reading diff files or use the patch tool to apply such changes. The tree of commits and object store is more easily explained (although it rarely get explained). But a lot of fellows I met are genuinely terrified of resolving conflicts, because they can't read diff files.

I genuinely think that git is an awesome tool. But you need to get familiar with some concepts like: What a commit is, what a branch is actually, why HEAD is important,... The operations like fetch, pull, push, rebase, cherry-pick, commit, checkout,... become way more obvious.