Reminds me a piece from Thoughtbot on using aliases for git commands[0]. My takeaway is that these systems work well for the people that made them because they have a deep knowledge of how they work. It's hard to get other people to adopt the systems they created, even if you can say "using this makes me 10% more productive".
Git always seems to be the focus of these "redesigns" because the commands are, granted, not intuitive. But is typing `gs` or `git c` better? Git's default API is documented, universally available and already in the muscle memory of most people.
I don't think the `gs` abbreviation is the big win here. Doing `gs` and getting a numbered list of all of your modified files is a big win though. Doing `git add 1,2,5,8` or git add `3-9` is really convenient.
`gs` is also GhostScript. I had a really amusing afternoon when the two commands were at war with each other. The funny part was that my app was actually using GhostScript extensively.
There is almost a nomadic pride in knowing the tool itself, and not a bunch of wrapper scripts around it. So if you find yourself on a different box, your 'productivity' isn't reduced as much. For editors such as vim, this really holds true, since it already has 99% of the features you really need built in.
Git always seems to be the focus of these "redesigns" because the commands are, granted, not intuitive. But is typing `gs` or `git c` better? Git's default API is documented, universally available and already in the muscle memory of most people.
[0] https://robots.thoughtbot.com/streamline-your-git-workflow-w...