I think there are many aspects of Git that are obscure/error-prone regardless of how well you understand its implementation. For example, the concepts of "ours

I think there are many aspects of Git that are obscure/error-prone regardless of how well you understand its implementation. For example, the concepts of "ours" and "theirs" when looking at changes depends on the current operation mode (rebase vs merge). Merging is unsafe-by-default, because it auto-merges even if both branches have modifications to the same file, and there is no guarantee that the resulting file is correct. There are numerous ways to collaborate on a git repo, with vastly different performance/usability implications, none of which is obvious when you start up (merging remote into local, rebasing local onto remote, squashing local commits; patches vs pushes). Not to mention that, for teams that work with a centralized remote repo, the whole concept of local tracking branches adds mental overhead for nothing, and extra work every time you want to push a change to a remote branch. You have to first pull, even if your changes and the remote ones don't touch the same files. Which of course means that, if you had a dirty worktree, you actually need to run 3 commands - one to stash your changes, one to pull, the actual push, and now an unstash.