Git shortcuts like you've never seen before | Hacker News Reader

Git shortcuts like you've never seen before

github.com

160 pointsadito22 comments

Very clever!

I had a problem with the installation script failing quietly. Just add this to your ~/.bash_profile to install:

  [ -s "$HOME/.scm_breeze/scm_breeze.sh" ] && source "$HOME/.scm_breeze/scm_breeze.sh"

Not just git shortcuts: the idea of a short and fast way to switch between projects through a project repository is of mindblowing simplicity. That's going to save me a lot of keystrokes...

Or you could just add the directory all your repos are in to your CDPATH ...

export CDPATH=.:$HOME:$HOME/repos

or use autojump/j/z/ etc.

I like it, but these tools are really starting to feel like a very cumbersome reimplementation of TortoiseGit.

I agree with you - every time I see some new fancy GIT shell, and all the accoutrements that must be set up in the shell to get some sort of 'application intelligent integrated development shell' I feel like its 1983 and we're building GUI's with ANSI all over again.

Of course, I'm insanely jealous of these git'ologists with their fancy shells .. I'd love to have the patience to sit down and learn their wizardry .. but in the meantime, plain ol' git needs to be learned, can be learned, and doesn't require arcane insertions into ones .bashrc before one can be productive. Nice to see it, but no thanks: I'll stay plain, just coz.

> arcane insertions into ones .bashrc

Are there particular changes to .bashrc that you think are arcane, or do you mean that any change to .bashrc is arcane?

Just the idea that the installation of an "app development environment" starts with modifying my bashrc, and thus my entire shell, bothers me. This may not be a rational fear, but as a crufty old Unix guy, it a 'smell' to me.

Its just not clean - there are too many opportunities to have something end up in there that breaks something else. My .bashrc is not an /etc.

I know, I know .. there is no other way to have a fully super-duper shell environment with pretty colors and notifications and other .. GUI-like elements .. without tweaking my prompts and touching my vars and so on. But, hey .. couldn't the same concept be built up as a real application, after all, which spawns its own shell and leaves my system defaults alone ..

it would be relatively easy (and I'd be surprised if someone hadn't scripted it to make it easier) to have a set of project specific configs which you merge into your global configs and exec a subshell per project. If you did it inside screen/tmux then you'd be able to switch between them easily as well.

The main issue I have with discriminating shells like this is that I tend to have a whole bunch open, and use the first I find that isn't already doing something useful. This means a lot of the time it's using features that technically 'belong' to a different project.

Yes, fair point. That's a good argument for using the git-number plugin instead, which has similar core features. The scm_breeze plugin didn't seem to like my hostile Cygwin environment, I'll try out git-number tomorrow, it should be a bit easier to get working. At first I was put off because I didn't know where it was putting its state. I see now that it is a text file in the .git directory, which on reflection is neater than the environment variables scm_breeze uses.

For people that use them a lot, smart text-based UIs can be much faster than GUIs (yes, even in 2012). Having the drag around the mouse and click eventually becomes cumbersome as well. But in the end it comes down to preference, I guess.

Using the keyboard is often much faster than the mouse if you know what you're doing.

I think I want it for the file shortcuts alone. Those will save me tons of keystrokes.

If you use bash or zsh, you might want to check out CDPATH. From the bash man page:

  CDPATH The search path for the cd command. This is a colon-separated
  list of directories in which the shell looks for destination
  directories specified by the cd command. A sample value is ".:~:/usr".

I think what he means is the $e1, $e2, ... shell variable shortcut. Not the `cd` to some directory.

Beware: CDPATH can wreck some eye-gouging pain when compiling ruby gem extensions.

And by eye-gouging pain, I mean that it takes you an extended period of time to determine why you can't bundle env-js when everyone else seems to have no problem. A simple export CDPATH="" resolves the issue with no problem.

"git add -i" has a similar number-as-a-filename shortcut out of the box but this is much better. I do a "git status" followed by something like "$EDITOR $e1", many times a day.

I have something similar configured with Vim + Fugitive. I use leader+g to prefix git commands, comma being my leader key. For example ",gs" is for git status, ",gb" for git blame, and so on.

Do I want something similar in my shell? Hell no. That would add ambiguity and make tab completion less efficient.

That giganourmous prompt takes too much screen space. Having a few characters left to type at the end without switching lines doesn't seem very appealing to me. At least put a \n somewhere. For the directory name I'm also a fan of \w and PROMPT_DIRTRIM

I like it but it's kind of slow on my macbook I understand this make much more thing but sometime i have to wait for 1/3 second until it get switched to the new repos. Nice work tho, I guess I just need a SSD upgrade (sigh)

But I like typing.

Me too! I actually bought myself a Topre RealForce keyboard just to ewnjoy it even more.

Knowing vanilla git commands is still important too.

Reply on news.ycombinator.com