Or, you know, that is irrelevant when the person using a GUI makes fewer errors than those who aren't (which has broadly been my experience as well).

Even someone who perfectly understands git can make a typo or have a brain-fart of a day. A GUI significantly reduces the chances of something like that for all users.

Sometimes dev obsession with tool purity does more damage than good.

You're always one git reflog away of undoing the brainfart. Once you know the CLI well enough, you manipulate the git data model easily. When you're using a code review tool like gerrit, it's impossible to do something you can't undo.

A well made GUI conveys those semantics more clearly than the default command line interface. Automation is easier from the CLI, but I wouldn't be surprised if a GUI turned out to be best for manual interactions.

(Note: I use the CLI almost exclusively.)

Conflict resolution in a GUI with 3 way merge really beats out a command line.

Doesn't really make the interface any less crap; though I've yet to see a GUI that didn't shell out to the command-line interface (which almost always makes them very unreliable).

I believe GitUp directly links to git library and doesn't use a command line shell.

Yes, GitUp actually ships its own git library.

Yeah, I would guess that the parent commenter has a heavily graphical workflow based out of a big honking IDE like IntelliJ. For people doing development in a console anyway, it would take more time to start a git GUI and wait for it to launch than to be done committing and pushing from the CLI.

The counter argument is that if you make an error using the CLI, you end up spending more time fixing it than if you just had the GUI open and watching your repo already, and simply switch to it when you need to commit/push.