I don't think that's true, especially for complex command-line tools.
Reading the manual, especially when it's well written, can help you understand why design decisions were made with the tool. We're not talking about a simple tool without safeguards. We're talking about a complex tool with a lot of interacting pieces.
You do read the manual on that airliner as a pilot because it's your job to know the systems of the airliner. You do read the manual on the sonar system in the submarine, because it's your job as a sonar operator to know the system.
I dislike the shiny-plastic-button mindset that seems to infect everything these days. Professional tools tend to be more flexible and more complex than consumer tools, because professionals often need to do more, and get more out of those tools. Git is not Dropbox or WinZip. It has a far more complex function. If you have to read the manual to get full use from a tool, that's not losing, that's learning. It's part of the job.
> I don't think that's true, especially for complex command-line tools.
That's the issue. The interface a person sees, should be minimal when possible. Git can't claim it's not needlessly complex when tools like Mercurial and Sapling exist.
> You do read the manual on that airliner as a pilot because it's your job to know the systems of the airliner.
Man, if you are comparing Git to an airliner, you do realize people allowed to touch a real aeroplane consoles need months if not years of exams and hundreds of hours of practice in simulators? Are you saying Git should require the same? Because then the analogy doesn't work.
Any CLI that would require months of reading the manual and practising in Git sandbox would be deemed too complex for all but the most masochist of devs.
Git doesn't have to be that complex, but its fundamental file based "abstraction" combined with keeping it exposed to end users leads to problems.
As someone said, Git isn't a Version control system, but a Version control toolkit, that you shape into a system. And everyone has a subtly different way of thinking how it should work, so you end up with some very bizarre workflows.
> I dislike the shiny-plastic-button mindset that seems to infect everything these days. Professional tools tend to be more flexible and more complex than consumer tools, because professionals often need to do more, and get more out of those tools.
And I dislike the RTFM mentality that is pervasive in the OSS sphere, but here we are. I don't want to think about what exactly the Git is doing, and "Why is Submodule eating my directories?". I want to write code.
Look, it's fine to RTFM when it's you and your buddies are writing a kernel in 1980. Not when it gets used by millions of developers.
Reading the manual, especially when it's well written, can help you understand why design decisions were made with the tool. We're not talking about a simple tool without safeguards. We're talking about a complex tool with a lot of interacting pieces.
You do read the manual on that airliner as a pilot because it's your job to know the systems of the airliner. You do read the manual on the sonar system in the submarine, because it's your job as a sonar operator to know the system.
I dislike the shiny-plastic-button mindset that seems to infect everything these days. Professional tools tend to be more flexible and more complex than consumer tools, because professionals often need to do more, and get more out of those tools. Git is not Dropbox or WinZip. It has a far more complex function. If you have to read the manual to get full use from a tool, that's not losing, that's learning. It's part of the job.
And yes, I have read the Git manual.