" I reject this out right. Git is a very simple command line tool. "

That's great, but most people would disagree, using the argument that there are rather a large number of variations of commands.

Can you think of another 'command line tool' with more complexity?

Git questions are amply popular on Stack Exchange. It's not that hard to use most other commands. All you need is -help.

"I'm not scared by this at all, so I have no idea what you're talking about."

It's 'scary' because it's ostensibly a very basic question, with apparently quite a number of varied solutions, each of them fairly complicated, and apparently not without controversy.

The second to top answer starts with: "Lots of complicated and dangerous answers here, but it's actually easy:"

If you put on your 'Product/Manager/Investor/I want to make a thing, not tinker in intellectualisms' hat for a moment, it is 'very scary'.

How can answers to simple questions about a tool be 'dangerous'? Of course, it's because some of these operations will screw up a repo, or create undue confusion. That's not good.

Why are there so many variations in answers?

Why is someone making a diagram? If someone has to 'get out the whiteboard' to answer simple tooling questions, then there are added levels of abstraction - which could be fine - but why on earth is that necessary?

Why are people having to go down rabbit holes of 'possible dangerous operations' to do something simple?

There are literally 62 addendums and comments to the top answer!

This is the 'opposite' of a 'good product' and the opposite of 'easy' - it has red flags all over it to the point wherein I'm thinking that I wish there were administrative options to make sure bad outcomes cannot happen, to start.

Complexity is costly, expensive, risky. Git is already a 'secondary factor' in making a product, the software being the 'primary factor'. So we're having to invest in knowledge, risk, problems etc. with 'a tool to help the tool' ... and when we run into serious problems, who do we call?

I don't want my devs to be tripping over themselves, falling into holes, possibly unrecoverable situations, spending time solving problems they should not have to.

Does the problem we are trying to solve imply this kind of necessary complexity? I don't think so.

"Name a software engineering tool you think is simple/easy"

So the question really is - what kind of complexity (magnitude, necessary complexity vs. arbitrary, required abstractions etc.) does a tool provide vs. the value provided - that is the question.

Git provides quite a lot of power, but its constrained by its own complexity - for very standard operations, it's quite easy. But beyond that it's a mine field.

There are literally people on this thread indicating that they don't even allow themselves to use commands they don't know well. There are ample stories of people getting them into problems they can't get out of, loss of code etc.. Where else does this happen for tooling?

There is a 'Golden Rule of Git' of something never to do - this to me is a huge Red Flag. Why the hell is something that 'should never be done' - even doable?!? This to me is a perfect example of the 'unbounded' nature of the complexity.

Finally - I have actually never met a Git expert. All the smart people I know who are 'strong in Git' are often befuddled in various situations. Yes, that happens in software, but it doesn't need to happen with our code management systems.