I've heard this reasoning multiple times, but that doesn't make it right. Like you said, you ARE presuming something: That scripting and a (useless) base case are the most common usage.
How many people script Git? More importantly, how often do you change that script? Rarely, and rarely. That means it's FAR FAR less work for the scripter to look up the weird incantations to remove the "human" parts (like a quiet flag).
Conversely, the human is far more likely to write git commands impromptu, and I dare say, this is the FAR FAR more common use case.
That means Git (and a lot of these kinds of commands) optimize for the RARE choice that happens infrequently over the common case that happens often. That's horrible design.
TL;DR: Just because there's a consistent design philosophy behind obtuse linux commands does not make a good, helpful, useful, modern, or simple philosophy. If a library author wrote code this way, we'd all realize how horrible that design is.
> That scripting and a (useless) base case are the most common usage.
You're thinking as a user. I'm sorry, but the vast majority of linux systems are still servers and embedded systems.
Here's two versions of the Unix Philosophy
- Write programs that do one thing and do it well.
- Write programs to work together.
- Write programs to handle text streams, because that is a universal interface.
- Make it easy to write, test, and run programs.
- Interactive use instead of batch processing.
- Economy and elegance of design due to size constraints ("salvation through suffering").
- Self-supporting system: all Unix software is maintained under Unix.
Yes, scripting is a common use case (I use git in scripts! I use git in programs. You probably do too, even if you don't know it). Piping is a common use case. And I'm not sure what we're talking about that is "useless". I've yet to run into a command where the default is useless. Even though I have `alias grep='grep --color=always --no-messages --binary-files=without-match'` I still frequently run `\grep`.
But we're also talking about programs that are DECADES old. git will turn 20 this year. You're going to be breaking a lot of stuff if you change it now.
And look, you don't have to agree, that's fine. But I'm trying to help you get into a mindset so that this doesn't look like a bunch of gobbledegook. You call these weird incantations. I get it. But if you get this model and get why things are the way they are, then those incantations become a lot less weird and a lot easier to remember. Because frankly, you'll have to remember far less. And either way, it's not like you're going to get linux changed. If you don't use it, great, move on. But if you do, then I'm trying to help, because if you can't change it you got to figure out the way.
Man, we're talking about git. It has never subscribed to this philosophy (and most programs in *nix don't)
Git does about fifteen thousand different things with about fifteen million flags.
And it was never designed. It was thrown together as a kitchen sink of useful things with commands adding new and crazy incantations as new things were added.
"Just write this script to do the useful thing" is a weird hill to die on
How many people script Git? More importantly, how often do you change that script? Rarely, and rarely. That means it's FAR FAR less work for the scripter to look up the weird incantations to remove the "human" parts (like a quiet flag).
Conversely, the human is far more likely to write git commands impromptu, and I dare say, this is the FAR FAR more common use case.
That means Git (and a lot of these kinds of commands) optimize for the RARE choice that happens infrequently over the common case that happens often. That's horrible design.
TL;DR: Just because there's a consistent design philosophy behind obtuse linux commands does not make a good, helpful, useful, modern, or simple philosophy. If a library author wrote code this way, we'd all realize how horrible that design is.