The thing I really like of Git is the simplicity and transparency of its structure: a Git repository is a DAG of commits, each of which is a tree of blobs and d

The thing I really like of Git is the simplicity and transparency of its structure: a Git repository is a DAG of commits, each of which is a tree of blobs and directories, all of them linked by their hashes. On top of that there are tags and branches, which are labels for some of these hashes. That's all, essentially. This makes it very easy to understand what's happening in my repositories. It makes it easy to address data: if two repositories have the same commit hash, they have exactly the same history, nothing else to check. To me understanding the data structure is more important that understanding how that data is to be manipulated. Manipulation follows from the structure, not the other way around for me. So it's true that git's interface can be a bit confusing, but if you know what you want to get, eventually you find out how to do it. Much worse would be to understand if you did the right thing with a repository whose internal structure is opaque to you. Also, manipulation tools can be fixed, enhanced, redesigned, developed, and git's user interface has definitely progressed since its beginning. Data at rest is more difficult to fix if you laid it out wrong (as the transition away from SHA1 proves: that's one thing that was not engineered well enough at the beginning and it has a price now). So having a solid data layout is more important that having an easy interface. These are the reasons for my love at first sight with git.