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.

[0] https://robots.thoughtbot.com/streamline-your-git-workflow-w...

I hope more command-line interfaces adopt a similar pattern. I pet peeve of mine is searching for a package (irrelevant of the package manager) and then installing it. In terms of interaction, it goes on something like this:

   $ ${tool} search ${pattern}
   res1
   res2
   res3
   # I'm interested in the first and last package names.
   $ ${tool} install <grab mouse> <double-click res1> <shift-insert> <double-click res3> <shift-insert>
   # On a side-note, this can also be done with tmux copy-mode by appending the
   # results to a buffer, but I personally find that using the mouse is faster
   # in this case.

Enumerating the results of the search and doing a '${tool} install %1 %3' would be a huge improvement. I once offered to add [1] such functionality to freebsd binary package manager, but nothing came out of it (perhaps for good reasons).

[1]: https://github.com/freebsd/pkg/issues/1041

There's also scmpuff a "minimalistic reinterpretation" by one of my coworkers. I use it every day:

https://github.com/mroth/scmpuff

Maybe I'm mistaken about this, but from the screencast it looks like this gives you a single text prompt for editing commit messages, rather than a proper text editor. Not only is that a deal breaker for me, it really concerns me that people are going to start using tools like these that encourage you to write horrible (read: one incredibly long line) commit messages.

Hmm.

File numbering is already available via `git add -i`.

    git add -i
    u
    1,9
    <return>
    q

And you get a more powerful tool, and you're using regular git.

This essentially what the various emacs version control interfaces give you (e.g., psvn for svn, vc for generic any-vcs support, or magit for git), but right there on the command-line. Very cool.

I just added a file named "2" to my git repo to mess with users of these tools :)

I've been using scm_breeze for a couple years, and it really makes me more productive with Git.

My favorite feature is that after a `gs` all the files listed are bound to sh variables $e1, $e2, etc.

The file numbering thing is awesome, good job. (And, truthfully, I wish it existed separately because I want it, but not the other stuff).

I've been using scm_breeze for more than a year. I enjoy using git via CLI now because of it. Because of the numbering scheme I end up doing better commits as well plus time saved not typing out paths.

Big thumbs up to the devs & thanks!