> No, but by definition, Git's CLI doesn't scale for complex use cases.
How so? A CLI is where you run commands and things happen. Sometimes those things can be "complex", whatever your definition of that may be.
> No one would voluntarily use the CLI for doing a complex 3-way merge if they could avoid it.
And nobody does...? A manual merge is done in an editor or a standalone tool, not the CLI.
> Due to the complexity of Git's interface, it's too easy to make a mistake using the CLI.
Well, Git's UI can be intimidating for a newcomer, but once they're acquainted with the dozen or so commands they might need every day, they can define aliases for them, and mistakes are no more likely than with any TUI or GUI wrapper. Git by design gives full control to the user, so mistakes can happen, but this is no different than with most Linux tools. And if safety is a concern, then whatever hand holding a TUI or GUI does, the same can be implemented in a shell script.
> git commit alone has 40+ options
So? You would prefer less options? Less commands? Less flexibility?
Just look up what you need to do and how to do it, and stick it in an alias. Now you have a clean command purpose built for your use case, and you can ignore anything you don't use.
Or, you can use a fancy TUI/GUI wrapper that "simplifies" this interface for you, and then when you need to do something that the wrapper UI doesn't allow you to do, have to fall back to the original UI. I'd rather familiarize myself with the original UI, create the aliases and helpers that work best for my workflow, and not have to depend on someone else's idea of how I should use Git, or any other tool.