Some bad Git situations and how I got myself out of them

Most people just spout the same sheep-like line "git>svn" without being able to justify it!

Perl 5 -- I don't know enough about 6 to know whether this is still the case -- involved a couple of design decisions which worked well for one subset of people and did whatever the complete polar opposite of "works" is for a different subset of people.

One of those design decisions is the famous "there's more than one way to do it". Ask five Perl programmers to solve a simple problem in the language and you'll get fourteen solutions, and no way of knowing which, if any, is to be preferred in real-world use. Git similarly tends to have multiple ways of achieving a given goal, and endless words have been devoted to documenting them; nobody has yet settled which of them is or should be generally recommended, or if there even can be such things as generally-recommended ways to use git.

Perl also involves an incredible amount of memorization. The large collection of "magic" variables which can be read or set to determine language and local-scope behavior are daunting and can't be mastered through any process other than rote memorization. And the differing behavior of basic operations depending on context produces a combinatorial explosion of possibilities which, again, are not amenable to any technique short of rote memorization. The same is true in git: though there are underlying abstractions, the interface provided to them is inconsistent, varies depending on sometimes-invisible contextual factors, and ends up requiring rote memorization of commands and options and how they behave in any given situation.

Unfortunately, no amount of documentation or review by technical writers can fix this. A bad API can't be made good through better documentation, it can only be made good through being replaced with a better API.

So you don't have three hours to read the fsckin' manual that describes how git repository is organized? O_o

    git merge --abort

    git rebase --abort

Generally there are (roughly) three approaches depending on where you are in your journey from beginner to expert:

As a beginner, you need specific, detailed, step-by-step instructions: First run X, then run Y, finally run Z, if something goes wrong along the way, follow these other steps, if that doesn't work, ask someone for help.

Once you've moved beyond being a beginner, you understand how the different steps are connected, so you already know the intermediate steps and just need to be told the task at hand: do an X (e.g. "move these commits onto the other branch").

An expert fully understands all the inner workings and just needs to be told the big picture: this is what I have, that is what I want, make it happen.

If you try to instruct experts like beginners, they will be frustrated because it seems so tedious and you're not giving them the information they want: what you're trying to do. If you try to instruct beginners like experts, they will be horribly confused because they don't know how to make any of it happen without you laying out each individual step they need to follow.

A case can be made that a beginner should learn each individual operation by heart before moving on to the next one (like kata in martial arts) but this style of learning assumes you're willing to spend a lifetime perfecting a single art. It's unlikely git will stick around that long and for most of its users git is just a tiny (though important) aspect of their work.