The only downside to this is that it is hard for me to help people with git problems since I can only tell them what conceptually has to be done, not how to accomplish it using the CLI.
The only downside to this is that it is hard for me to help people with git problems since I can only tell them what conceptually has to be done, not how to accomplish it using the CLI.
If you're trying to teach a child how filesystems work, do you open a terminal and teach them `ls` and `cd`? No of course not. You use some kind of GUI file manager with a tree view.
I disagree. "What's happening behind the scenes" is not the corresponding CLI command - it's the actual modification to the commit graph, and GUIs are much better at exposing what is happening. Think about something like a rebase. Find any article explaining Git rebase. It will have diagrams showing what happens to the commits and those diagrams are exactly what a Git GUI displays!
To follow my filesystem analogy, when you move a file, the thing that's happening behind the scenes is that the file is moved, not `mv A B`.
> make it harder to recover from mistakes.
Also disagree. I'm not sure what you're talking about exactly but assuming reflog, then most GUIs don't support that and you're going to have to use the CLI in either case. But "GUIs don't cover this rare feature" isn't a reason to ditch them completely.
I agree there are a lot of awful GUIs though. It doesn't help that the Git website lists dozens of them and only 2 or 3 are any good. My recommendation: if you use VSCode, the Git Graph extension. If you want a standalone tools, SourceGit or maybe GitX if you're on Mac.