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
Just think how many person-hours were wasted by that team huddled around the monitor...
GIT: The Swiss-Army Chainsaw of Version Management.