No. Why do people think "professional" has to mean "poorly designed"?
But then, the rest of your post seems to miss the point of this thing entirely. You go on to say that you basically only need 10 commands...which is pretty much the insight that lead to Gitless in the first place.
In that sense, git is a professional tool. If you know everything about it, it doesn't get in your way. The problem is when you don't know everything about it..
The problem with git is the lack of coherence in its default UI. Multiple ways to accomplish the same task, git commands which perform incredibly different functions depending on (invisible) context, inability to decide whether commands or flags should act as the highest-level switches...
It is simply the case that, no matter how beautifully and cleanly designed git's internals might be, the interface it presents to them has zero conceptual integrity.
Visual SourceSafe springs to mind here...
Git, by comparison, is very flexible and allows you to do an awful lot, when you've learned it. You can learn SourceSafe inside out and still have it be a total pain in the arse.
Nothing in that interface is designed to aid in learning. Nothing in it is designed so that mastering one task provides discoverability or intuitability of how to perform another task. It is a complex mess of inconsistencies, discontinuities and obscurities which point more to a lack of design or even of someone with authority to perform design than to anything else. It can only be "mastered" through rote memorization, and bears no necessary or useful relationship to the underlying data models and structures whatsoever.
I have no particular view on how good or bad git's command line is - I have greatly enjoyed using SourceTree though, and the underlying DVCS seemed not to get in the way.
This idea that 'if you don't like the tool, it's because you're not good enough to use it, because you don't know everything about it' is elitist hokum.
many NTSB studies show that even master pilots with thousands of hours of training and flight time make (often fatal) mistakes due to confusion in understanding the cockpit readings
For example, the Army found that using glass cockpits doubled or quadrupled the accident rates in UH-60 and OH-58 aircraft respectively, increased it by ~30% in the AH-64, and reduced it by ~40% in the CH-47.
http://oai.dtic.mil/oai/oai?verb=getRecord&metadataPrefix=ht...
http://www.usaarl.army.mil/TechReports/2001-12.PDF
A five-year NTSB study found that although glass cockpits had twice the incidence rate of fatal accidents. The study concluded that glass cockpits do not show a safety benefit. This remains the position of the NTSB.
http://www.ntsb.gov/safety/safety-studies/Documents/SS1001.p...
http://www.ntsb.gov/news/events/Documents/2010_Glass_Cockpit...
http://www.ntsb.gov/safety/safety-recs/recletters/A-10-036-0...
The reality is that simpler is sometimes better. Mechanical instruments each do one thing and they do it well. Vacuum-driven systems are simple and extremely reliable. You cannot fly a 100% glass cockpit, period.
What glass cockpits really do well is information integration. That makes it easier to surface relevant information for the pilot but it also means that pilots have to handle more complex systems that are throwing more information at them, and yet also may not be throwing the right information at them.
This is an inherently one-way street, the reason we have the instruments we do is because they're relevant, you can't go hiding relevant information from the pilot. As such, NASA recgonizes that glass cockpits and cockpit automation impose a higher cognitive load on pilots. It's very simple and straightforward to interact with a traditional cockpit, but with a more advanced cockpit you also need to have a correct mental model of what's happening in the background, otherwise "cognitive mismatch" will result.
Just like any other abstraction - it's nice when they work but all abstractions are "leaky" to some degree or other and you need to know how it works and be able to route around the problem to fix the cases where it fails.
The long and short here is that experience and frequent training are the key factors in aviation safety and glass cockpits actually increase the requirements in this area. They're nice when they work but they certainly are no panacea.
http://human-factors.arc.nasa.gov/flightcognition/research/s...
https://www.thinkmind.org/download.php?articleid=achi_2012_1...
GUIs and "UX" are generally antithetical to making a computer do what it does best (automate things instead of creating more busywork).
I agree with you, but although CLIs are explicitly automatable, they are almost never are because most operations are one time deals. If you have evet set up a Linux server I think you'll understand what I mean. The CLI is also a usability nightmare with no discoverability.
Except for helping the 6 or so billion people in their daily lives, but hey, the iPhone would be 'better' if it just had 'bash'?
Read your email lately from bash?
Didn't think so!
Now, I use pythonista as a python-shell. Being able to chain a couple of commands and fix a good-enough solution saves a lot of time in many cases such as web scraping on-the-go.
I know this may be an extreme use case, but if iPad is going to be a laptop replacement we need to be able to get a way to speak with it without immidiate access to a laptop.
It's not a false equivalence at all.
The necessity of lower-level technology in the creation of higher-level technology does not imply that the lower-level technology is somehow 'better' or 'superior'.
You are using a UX right now to read and respond to this.
It's crazy to posit that 'UXs are inferior'. Positively wrong.
In the vast majority of cases, UX's are superior to shells. Maps, news, social media, browsing/buying things, listening to music, making music, photo editing - there are actually very few use-cases wherein the shell is advantageous. Even emacs is a UX of sorts.
GUI:s are superior for the specific (limited) use cases they are designed for, inherently since they were designed to excel at those use cases. They are however less optimal when you want to diverge from those use cases and create something new. This is where malleability/modability comes in, and where CLI:s, bash, scripting, programming comes in, and you can't use limited-scope apps for that.
All tools are best at what they were designed for, I agree with you there. I'm however not sure how I in your mind was wrong before. The two are intrinsically bound, but it's undeniable that apps can't exist without tools, but tools sure can exist without apps.
With all the security concerns and regulation regarding flight, it's easy to imagine how hard it is to move forward and innovate in usability.
I'm not saying upending git for something better would be trivial, but I don't want to constrain my imagination by thinking it's not possible.
If you can coherently explain what you need [git replacement] to do, and explain it simpler than you would explain git itself, then you have an outline of a superior tool.