Scm_breeze – enhancing your Git CLI workflow

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&#x27;s hard to get other people to adopt the systems they created, even if you can say &quot;using this makes me 10% more productive&quot;.<p>Git always seems to be the focus of these &quot;redesigns&quot; because the commands are, granted, not intuitive. But is typing `gs` or `git c` better? Git&#x27;s default API is documented, universally available and already in the muscle memory of most people.<p>[0] <a href="https:&#x2F;&#x2F;robots.thoughtbot.com&#x2F;streamline-your-git-workflow-with-aliases" rel="nofollow">https:&#x2F;&#x2F;robots.thoughtbot.com&#x2F;streamline-your-git-workflow-w...</a>

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:<p><pre><code> $ ${tool} search ${pattern} res1 res2 res3 # I&#x27;m interested in the first and last package names. $ ${tool} install &lt;grab mouse&gt; &lt;double-click res1&gt; &lt;shift-insert&gt; &lt;double-click res3&gt; &lt;shift-insert&gt; # 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. </code></pre> Enumerating the results of the search and doing a &#x27;${tool} install %1 %3&#x27; 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).<p>[1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;freebsd&#x2F;pkg&#x2F;issues&#x2F;1041" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;freebsd&#x2F;pkg&#x2F;issues&#x2F;1041</a>

There&#x27;s also scmpuff a &quot;minimalistic reinterpretation&quot; by one of my coworkers. I use it every day:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;mroth&#x2F;scmpuff" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;mroth&#x2F;scmpuff</a>

Maybe I&#x27;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.<p>File numbering is already available via `git add -i`.<p><pre><code> git add -i u 1,9 &lt;return&gt; q </code></pre> And you get a more powerful tool, and you&#x27;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 &quot;2&quot; to my git repo to mess with users of these tools :)

I&#x27;ve been using scm_breeze for a couple years, and it really makes me more productive with Git.<p>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&#x27;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.<p>Big thumbs up to the devs &amp; thanks!