> stashing is dangerous. I've seen many students loosing work with a stash pop requiring a merge which ended badly.
`pop` will no longer drop the stash if there is an error applying it; it did in the past.
There is a point where it is worth having at least one person on a team study the internals of Git vs. struggling with it constantly and possibly losing work---it will save time, energy, and work in the long run.
In the stash case, `git reflog` would immediately allow you to recover the lost stash. If you're in deep shit, `git fsck` is valuable until the commits are GC'd. Even if you don't remember the commands, you'll know where to look for them, or what to search for to find it. Or even understand that it's _possible_.
> nothing in the tool gives you enough context if you don't explicitly ask for it, which supposes you need to know you need it, and what "it" is.
There are numerous PS1-augmenting scripts available; git even comes with one. But I agree that it otherwise would be incredibly frustrating for beginners.
> branch switching is a hard
I've heard many criticisms when watching others learn Git and teaching others, but this is one of the only things that never comes up once they've done it a couple times. Stash and switch. Or commit WIP and switch.
> the whole syntax is impossible to discover, even for very common tasks: git checkout HEAD^ /file/path, git rm --cached, etc.
I learned pretty much everything I know about Git from experimentation and, most importantly, the manpages. If someone is unaware of manpages, the documentation is online. Failing to read is failing to discover, yes.
> git assumes you know what you are doing. Which means it let you destroy history with rebase, loose stuff with stash pop, create detached head, make force push, and all it all put yourself in many situations a beginner won't understand, and above all won't need.
Yes, this is fair. But also essential. I have recovered from more fucked situations that I could have imagined, and have helped others do the same---situations where I would have otherwise lost work.
But it's a matter of teaching someone fallbacks. If you accidentally screw up everything with a rebase on , `git reset --hard origin/`. If you can't remember that, open tig / gitk / a web interface / etc, find the hash, and reset to it. If you are on a detached head, check out a branch. You shouldn't be force pushing, but that's nothing the manpage can't help with.
It all comes back to the basic understand that nothing is ever deleted in Git until garbage collection. There is always a hash to recover. Sometimes I just lazily scroll up in my terminal and grab it.
But your first point:
> git checkout does so many different things. Git check file, git checkout branch, git checkout commit all do different stuff, and don't get me started on the option flags
Yes, this is unfortunate.
tl;dr: Research your tools! Poke around the manpages or online. Know what you don't know so that you know where to look later. And there is always e.g. gitk to fall back on for certain things---I see others on my team do that as well.