[blakeyrat]

I do ok with text, probably purely due to practice. (Playing MUDs, writing stories, etc.) I've learned what kind of things trip-me-up and carefully read everything twice before hitting submit.

To be perfectly honest, the main problem I have with CLIs is that there's no safety net, and a single typo could lose hours of work or loads of files. There's no Undo, there's no Recycle Bin (or Trash Can or whatever you want to call it). It's unforgiving and I make a lot of errors, and the combination of those two things is that I have zero confidence so I avoid them whenever possible.

I can't think of any development-related task I've ever need to do where it's helpful to "compose tools into pipelines", except building the solution which Visual Studio just kind of magically does for me.

And yes, obviously I know Git is best used from the CLI. I hope you realize how off-putting and discriminatory that feels to somebody like me... especially now that it's become a de-facto standard before it has a single reasonable GUI in Windows. I can't even imagine how a workplace adopting Git would feel to a person with a real physical disability.

[angersock]

So, on Windows, TortoiseGit isn't too bad. I like some of what the Github client does, but it gets confused sometimes and that terrifies me. For a while I maintained our in-house Git tool that enforced a particular workflow--a nice GUI that had buttons for particular work stages and checked to make sure the devs were following process. :)

That said, we kept getting nibbled by little issues the interfaces had glossed over, and eventually I just sat down with the team and started practicing and reiterating how to do what we did with git, and made sure our team's wiki had explicit reference instructions. They weren't really CLI folks, but within about a month they were all fine, and I cleaned up any messes they made and helped them gain confidence even after big oopsies (like deleting the master development branch on a weekend).

I think that if your development environment is more server-y ('nix, basically) you'd be getting more exposure and practice with composition of tools and CLI stuff. Don't give up!

[blakeyrat]

I develop server apps all day. We don't use Unix servers, we use Windows servers. Which is great, because it means I can use C# which is one of the few programming languages available that actually has competent GUI tools.

Your post is misconstruing my point quite a bit. I don't want to learn CLI tools. (Why would I, when they're clearly inferior to GUI tools I already have? From my perspective.)

What I want is for developers of programming tools to be more aware of usability issues in their products, and to test their products with a wider audience of users. (It's obvious the authors of Git never thought for even a brief moment about usability or accessibility issues.)

Usability isn't just for mobile apps; all applications should have effort applied to make them as usable as possible to as many different kinds of users as possible.

[MasterTurdle]

These CLI tools are generally developed by and for * nix developers.

These developers generally prefer CLI tools for a bunch of reasons: their power, flexibility and ease of automation, integration and combination, standardized in/outputs, use over SSH and speed.

They prefer making CLI tools for all these reasons, and because it takes much, much less time to write a good CLI tool than to write a good GUI tool.

So, if you prefer hand-holding and mouse-holding, fine, use Microsoft products, they have something for almost everything you could need.

However, you can not expect developers, who work for free, to spend their free time to solve a problem they don't have, for a platform they don't use.

If you want these as GUI tools, why don't you build them yourself? No one is stopping you.

Edit: readability

[blakeyrat]

> These CLI tools are generally developed by and for * nix developers.

Duh, I know that. But I'm not a Linux developer, I don't want to be a Linux developer, and I still have to use Git.

> They prefer making CLI tools for all these reasons, and because it takes much, much less time to write a good CLI tool than to write a good GUI tool.

Too lazy to make software properly; gotcha. They wrote about 1/3rd of a good source control program, then just kind of gave up, stopped, and called it "done".

> However, you can not expect developers, who work for free, to spend their free time to solve a problem they don't have, for a platform they don't use.

No; but I'd expect someone to do it. And it would be nice if open source developers actually felt a bit of guilt or remorse over how difficult their products are to use.

> If you want these as GUI tools, why don't you build them yourself? No one is stopping you.

I already have a job. My job is significantly more unpleasant because I have to work with Git. Volunteering my time to work with Git more is not appealing to me.

[dragonwriter]

> To be perfectly honest, the main problem I have with CLIs is that there's no safety net, and a single typo could lose hours of work or loads of files. There's no Undo, there's no Recycle Bin (or Trash Can or whatever you want to call it).

Incidentally, there's no reason that that is inherently a feature of CLIs. There's no reason that "delete" really being "reversibly identify as pending delete pending a separate action" like the Recycle Bin workflow is tied to GUI vs. CLI except historical accident.

[blakeyrat]

> Incidentally, there's no reason that that is inherently a feature of CLIs.

Correct.

The problem is cultural, not technological. And there seems to be zero interest in the open source world in fixing (or even improving!) their CLI environments.

[Vendan]

Check out SmartGit http://www.syntevo.com/smartgit/

I showed it to my boss, said "This is easier to use then cli, and faster", and he said "Pff, $80 bucks?". I had a license about 30 minutes later.

[brudgers]

What shortcomings have you experienced with SourceTree?

[blakeyrat]

The UI is so low-quality I can barely stand it. It looks like someone just took the Git man page and said "let's make a button for every switch! That's our UI!" and plopped it down in the window. There was obviously no design or usability testing involved anywhere in the process. It practically requires familiarity with the CLI client before you can figure out how to do anything at all.

It frequently shows active buttons and menu items that don't actually do anything when pushed. So they can't do one of the most basic GUI operations correctly-- dim stuff that's not relevant.

Simple mistakes like the process for undoing the latest commit being to click the commit before it, then selecting "rewind to here" (or something; this is from memory.) Because God forbid you just let the user click the latest commit and choose "undo", they might discover that without having to Google it!

But what really prevents me from using it is how goddamned slow it is. Right-click a file, choose "Revert", and maybe the file will actually be reverted in 10-15 seconds. If you're lucky.