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 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.

This is why I start all of my git aliases with capital G. Gs = git status, Gc = git commit, etc.

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.

Exactly, vim was the other tool I had in mind when I wrote that.

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

With zsh:

$ $(tool) search $(pattern)

res1

res2

res3

# press arrow up, home, r= (`, end, `)

$ r = ( `$(tool) search $(pattern)`)

$ tool install r[1] r[3]

Or use a fuzzy matcher...peco and fzf (the go version) are my favorites, since they install with no dependencies on a runtime, but there are python/ruby options (fpp, selecta, percol) as well.

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

https://github.com/mroth/scmpuff

Thanks for sharing this! As a fan of scm_breeze & golang this looks fun! (possibly faster too I would assume)

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'm not seeing anything close to what magit provides for git add --interactive.

Yeah, magit really is incredibly quick and convenient. I often go so far as to have an emacs session open "on the side" just for magit, even if I'm using some sort of IDE. I'd even go so far as to say that it might even be worth learning (just enough) emacs for!

It would be incredible to have something with magit-like efficiency that could start up in an instant (unlike emacs). I'm aware of "tig", but it seems rather limited, unfortunately.

A name that doesn't sound identical to "maggot," I guess. I've always wondered what the creators were thinking when they chose that name.

It seems a pretty obvious portmanteau of magic + git. I always said it with a different rhythm: "ma-git" rather than "mag-it", so that might also be a factor.

I always pronounced the G softly as in 'magic' so it took a while for the criticism to register. Gonna be honest, I like magit with a hard G, maggots 'n all.

maybe they were thinking of a humorless git.

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).

Something that matches what you're looking for was just posted above: https://github.com/mroth/scmpuff

I use my own tool that works with any command: https://github.com/robbiev/numberwang

Nice tool. Suggestion: make it clear in the README that it can take more than one number; it wasn't clear to me until I read the source.

Done, thanks for the feedback.

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!