Hyperbolic.
Fixing mistakes is easy if you understand the underlying data structure. Once you can conceptual map the structure into the intended form, you figure out what operations (verbs) you need. Then it’s a matter of mapping the operations into concrete command lines.
There are a ton of things that can happen during a merge, for example. Does anyone know what a smudge filter actually is? Why are there branches, and also tracking branches? There are refs, heads, objects, and blobs, and not all of those have the same operations (list, show) defined on them. There are changesets but also snapshots. Why do some commands have a --porcelain flag and others don’t? Did you know Git has garbage collection? You can’t rename a file in Git. What’s the difference between branches and tags? These are all things that are really discovered only through relentless trial and error.
Everyone seems to be learning git by staging and committing some code, then making pushes and pulls, with all the rest added on top of that. Basically, learning the UI first and only then figuring out what that UI actually does. I'd rather advice to start by learning what refs are and how commits actually look like on a imagined repository graph, since that (along with the working tree) is what you're actually manipulating most of the time - all the rest flows quite naturally from that. Merges and rebases are quite simple from that point of view, and the way heads, branches and tags work make perfect sense then. Objects and blobs can mostly be perceived as implementation details, but once you realize that there are no actual changesets in git at all, they quickly stop being obscure as well (and then the fact there's no such thing as file rename becomes obvious too). And when it comes to garbage collection, git lets you know that by itself on a big enough repo ;)
When you start learning the UI already equipped with that knowledge, it simply makes much more sense.
Git's biggest sin is not having a clear separation between the abstraction it presents to the user and what's essentially its internal implementation. It's like an UI made for people who not only work with git, but also on git. The result is poor UX, which is why you need to learn what git does first before learning its UI. But poor UX doesn't mean it's rocket science - it only means that you'll have a better time learning from an external resource.
Clean and smudge filters seem interesting, I wasn't aware of them, thanks for mentioning that!
$ git-mv <old_name> <new_name>This only leads to confusion once you use 'git mv' and edit the file significantly enough in the same commit. "Why doesn't git show that it's a rename? I explicitly told it so! Did I do something wrong?"
Just because a tool is intended for engineers doesn’t mean it isn’t “hard” if it requires way more learning than any other tool in that engineer’s tool chain. Git is hard, even if you happen to have mastered it by now.
And how many of them use word processors and/or spreadsheets and don't bother learning about the internal structures of file formats?
* https://en.wikipedia.org/wiki/Microsoft_Office_XML_formats
Have you ever examined the bitstream of gzip or the structure of tar, even if you downloaded source file in them? Do you know the structure of RPM and/or Deb packages (depending on your favourite distro)? Do you know the voltage pattern of the Ethernet signals that go down the cable (or waveform of the Wifi / LTE radio signal)?
There are only so many hours in the day, and not everyone wants to (or has the time) to go deep into every rabbit hole.
This is the problem. A tool that hides its internal structure but requires you to rebuild it in your head is poorly designed, full stop. The reason git is difficult to deal with is that it is a low level abstraction over the underlying data structure, but simultaneously hides that complexity until suddenly you need to be aware of all of it.
I always recommended reading chapters 1-3 and skimming chapter 7 to people who are just getting started with Git.
Some of this I was able to figure out about thinking through the problem, considering alternatives and some had to be done through reading.
My approach to learning is not so much "bottom up" [e.g. I can't just read a book from chapter 1, or some website that claims to explain everything].
$ git-status
$ git-log --graph --oneline --all [--reflog]
$ git-branch -avv
$ git-config --listCue the old joke:
> git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space.