>>On Linux, a GUI is mostly nothing then a wrapper for command line tools - and only half thought in most cases. Not that M$ interfaces are much better, it goes worst by the day.
>
>As an example, I suspect the web-based Exchange Admin Center (EAC) is ultimately just a front-end for building Exchange PowerShell commands that get run on the back-end Exchange server.
>
>I can see the appeal for going this route - if you can access battle-tested shell functions, why not use them?

Shudder. The whole idea of a MS web server running Powershell in the back. Don't get me started.

Anyway, there is nothing wrong with the idea. If
a, the function of the GUI is not crippled
b. the GUI is up to date with the script.
c user understand what's going on

This is something you would not suspect on a Linux based system. The script may work, but GUI might be versions behind, if maintained at all. Nothing the common Linux coder likes to do. Like documentation.
The problem with git is on c, a GUI will not help the former user of Mercurial understand the way git ticks. And this is mandatory. Or, from my POV, it's so much work to understand it, that finaly the GUI is superfluous. The GUI will not integrate into VFP's IDE, so I need to do this myself- what requires the shell command anyway.
I doubt a git GUI exposes a interface to handle git commands.
;)