You're probably right. I, though, know just enough GIT to get by. In every case where things have gone seriously pear-shaped, it's just quicker -- like days quicker -- for me just to throw everything to the wind and clone the repo again. Reading up how to do the proper thing a recover will just take me order-of-magnitude longer, and frankly, I don't have the time.

Just think how many person-hours were wasted by that team huddled around the monitor...

GIT: The Swiss-Army Chainsaw of Version Management.

Once you understand a few basic things like the underlying git model, and what the reflog is, you can basically get out of any situation. Totally worth the time to learn, it'll save you a ton of time

The interface should be what saves a ton of time, and should not expose the underlying technical model (especially because that model may change at some point)

I don't think it's reasonable at this point that git's underlying model ever changes substantially. Essentially, it is the interface that's stable over time.

It's also the easiest way to understand git.

You could learn to read by memorizing the shapes of thousands of words without learning the alphabet or how it matches up to sounds. I'm sure people have done it. But the failure mode when encountering a new word is complete and utter bewilderment that this new shape is unfamiliar, rather than a graceful degradation you get if you understand the alphabet. The same is true of git.

This is funny because the lack of consistency in Git's user interface forces you into memorizing the shapes of specific words (commands and arguments). To spell it's language.

The UI does a remarkably good job of hiding the elegant underpinnings from you.

> it's just quicker -- like days quicker -- for me just to throw everything to the wind and clone the repo again

In this case, I have a single suggestion for you: Give the following extra arguments to git clone.

  --reference /path/to/existing/clone/ --dissociate

This will download objects from your existing clone rather than from the remote repository, thus saving you a great deal of bandwidth if your repo is appreciably large. Also, this operation is absolutely safe. It will only copy objects over into the new clone that are referenced in the remote repository.

Every time I start to dig super deep on problems like this I stop for a second and wonder "just how important is it I fix this error" and "can this be solved by just paving over my local and reapplying my changes...". Most of the time the answer is not extremely and yes.

It's true that for any given problem, learning how to fix it probably isn't worth the time. I've found the long-term benefits of taking the time to learn how to fix every problem I've run into (and importantly, understand what the things I'm doing to fix it do) to be very worth it, though. Over time I've had to google how to do fewer and fewer things, and when I do still need to google something it takes me much less time to understand the answer and how to apply it.

As a polygot developer working in multiple languages, editors and ecosystems, git has been the one tool that I'm always using, and that makes it always worth investing more time into learning how to use it better.

Same really. I'm considered a "git expert" at work and the extent of my expertise is:

"This merge went completely sideways. But I haven't pushed anything."

"Okay, do this to export the commits you made as a patch file. Move those somewhere safe. Delete your repo. Reclone. Apply the patches. Commit. Start merge over again."

Also I can recognize whatever that weird error message is that means someone deleted a file in one branch and I edited it in another. Usually results in just "git rm (file); and git merge --continue".

> This merge went completely sideways.

  git merge --abort