[RadiozRadioz]

The reason people on here tend to dislike those types of tools is because they've probably been the ones who had to fix the tangles people get themselves into by using those tools. Tools that obscure details in favor of simplicity are fine in some cases, but version control is an inherently complex problem domain where having those details is important.

In my experience mentoring juniors new to git, those who are just given a few basic commands don't create as much of a mess because they don't have the commands required to make a big mess. When they do make a mess, it's usually because they've copy-pasted something from the internet, and most will acknowledge that blind copy-pasting _feels_ wrong. Give them a GUI, and suddenly there are buttons to create all sorts of unholy mangles right at their fingertips.

As a really simple example, one of the most frequent things I see from juniors using git GUIs is adding files to a commit that they didn't intend to (say stuff that's not in the .gitignore, but doesn't belong in the commit). In the CLI, they probably don't know about -a, so they would be forced to add files/directories individually and think about what to include. Most GUIs I've seen include a "Stage All" button front-and-center, which is very tempting for a new user to click (or, worse, they make staging an opt-out thing). I do not know if this specific example is the case in GitHub Desktop, it's something that I see regularly.

I agree with your last point. I think git GUIs are best for users who already know what they're doing and find that a GUI speeds up their workflow.

[__blockcipher__]

> As a really simple example, one of the most frequent things I see from juniors using git GUIs is adding files to a commit that they didn't intend to (say stuff that's not in the .gitignore, but doesn't belong in the commit). In the CLI, they probably don't know about -a, so they would be forced to add files/directories individually and think about what to include. Most GUIs I've seen include a "Stage All" button front-and-center, which is very tempting for a new user to click (or, worse, they make staging an opt-out thing). I do not know if this specific example is the case in GitHub Desktop, it's something that I see regularly.

I agree with your general point, but on this specific point I'd be remiss if I didn't mention that I see an insane amount of people regularly use `git add .` to add every file, because they don't realize they actually want `git add -u` (only add already-tracked files) 99% of the time.

But as a counterpoint, since your example is about giving devs a limited set of commands, you naturally wouldn't be giving them `git add .`. But it's definitely something that frequently comes up in crappy git tutorials.

[OkayPhysicist]

You didn't mention the fact that the GUI tools often lack functionality that's present in the CLI. Like git notes (looking at you, GitHub, who previously HAD notes support, but dropped it) or worktrees (Sourcetree lets you view worktrees, but provides no interface for interacting with them as worktrees, rather than just another repo). Or they hide basic functionality, like git ammend, or give less useful error handling advice than git itself (Sourcetree, I love your commit graph, but your error messages are worthless).

[squeaky-clean]

  git add . 
  git commit -m ""

Are like the first 2 got commands anyone tends to learn after git init or clone

[dullcrisp]

> they probably don't know about -a

How are you going to keep them from learning about -a?

[xmprt]

When I first learned git, I had no idea what staging meant and the differences between A, M, D, R, AM, etc...

Only some time later (albeit a short time) I learned about -a, at which point I had a bit more understanding of the statuses and what it meant to stage a change. If you gave me -a before that, I would have never understood those things properly.

[make3]

the other thing is that this likely doesn't work over ssh

[sdiacom]

It does. GitHub has been soft-deprecating HTTP for years now.