>The idea is commit snapshots of the whole project. Once set up right a simple
>

>RUN "git commit -a"
>

>is enough in most cases

Eh no. There's a lot more to git than `commit`.

Especially If you work in a distributed environment. Sure if all you want to do is commit locally that's fine. But if you're like me you actually use Git for diffing, code sharing (public and private), code forensics (ie. searching code for changes), and of course you need to push the changes upstream so they can be shared. There are Pull Requests and PR management etc. and IDEs (or even sites like GitHub) make all of this tremendously easier than using the Command Line. There's an entire eco system around Git commands.

Yes you can use the CLI but the commands are non-intuitively named and often require even less obvious switches - it's one thing to remember 2 or 3 commands, but quite another to do this with a couple of dozen commands and switches. At least it is for me.

Don't get me wrong - I'm happy that CLI functionality is there as I can use it to automate many tasks, but for day to day operations I have my Git tooling (I use SmartGit) open and frequently pick and choose commits (or discard) and there's no way I would do this as efficiently from the command line - just the typing alone even if I remmebered commands would take more effort than picking files and clicking a button. I almost never do a wholesale commit for example - almost always (especially with Fox) there are files that I don't mean to commit or need to discard for example.

+++ Rick ---


>After that, there is minor need for fancy desktop git apps.
>
>The greatest problem is, that git is best with text sources - and it's a struggle and extra step/layer with the conversion. But then it works like a charm. If one come over the fear of not commiting the binaries, just the text representation.
>
>My problem with PE is, that it (must) keep the projects open in background, and dies on every CLEAR ALL - what for a lot of the bin vs text transformings is mandatory.