

Announcing gitsh: A dedicated shell for git commands - creativityhurts
http://robots.thoughtbot.com/announcing-gitsh

======
mvanga
Do we really need a shell for this? If you're reusing some of these so often,
why not just alias them in your bashrc? The interactive shell requires way
more key-presses than any of my aliases not to mention sticking me into a
shell that I need to exit out of later to get back to my development
environment.

    
    
        $ cat ~/.bashrc | grep git
        alias gitc='git commit -a -s'
        alias gitls='git log --pretty=oneline'
        alias gitb='git branch'
        alias gitca='git commit -a --amend'
        alias gits='git status'

~~~
gregwebs

        $ cat ~/.alias
        alias g='git'
    
        $ cat ~/.gitconfig
        [alias]
          st = status
          br = branch
          co = checkout
    

I don't see anyone else doing g='git' but I don't have to write out an alias
for each command. For less frequently used git commands I forget an [alias]
shortcut but I can always use the 'g' shortcut.

~~~
nperson
If you want to keep bash completion on working when having git aliased to g,
try to add this line to your .bashrc:

    
    
      # Complete aliased git, too.
      complete -o default -o nospace -F _git g

~~~
mythmon_
I was curious about this, so I checked: zsh will preserve completions if you
`alias g=git`.

------
mickeyp
Even if you're not an Emacs user I recommend you try out Magit inside Emacs.
(And if you do use Emacs, you should definitely use it.)

I wrote an introduction to Magit a while back. Magit has a very simple and
understandable "context menu" interface that gives you access to _all_ of
Git's functionality, and then some. In other words, it's not a pared-down
environment like a lot of frontends.

[http://www.masteringemacs.org/articles/2013/12/06/introducti...](http://www.masteringemacs.org/articles/2013/12/06/introduction-
magit-emacs-mode-git/)

~~~
Myrmornis
I use magit a lot. It is good, but it would be nice if magit-status, and log,
were faster. I think it does unnecessary things by default. Is there a way to
fold all diffs in a buffer?

------
m4r71n
I've been using Ryan Tomayko's git-sh [1] for years. It provides very similar
functionality and consists of just a handful of Bash scripts.

[1] [https://github.com/rtomayko/git-sh](https://github.com/rtomayko/git-sh)

------
akerl_
This is definitely interesting, and I might check it out for the couple of
times a week that I have to do complicated stages of commits or rebasing.

Generally speaking, though, I love git because I don't have to break out from
my normal flow to use it.

My use case is potentially very different since most of my projects under
version control are personal / single_committer, but I've saved myself some of
the typing by aliasing common git commands to short codes: 'git add' becomes
'ga', 'git commit' == 'gc', 'git push' == 'gp'. That way, committing/pushing a
bug I've just fixed becomes `gc -am '$message' && gp`.

------
kenny_r
I prefer native system packages to tarballs, so here's a script [1] to
generate .deb and .rpm packages using Jordan Sissel's FPM [2] (gem install
fpm).

[1]
[https://gist.github.com/rasschaert/8915657](https://gist.github.com/rasschaert/8915657)

[2] [https://github.com/jordansissel/fpm](https://github.com/jordansissel/fpm)

------
stdbrouw
What would also be neat: a "generate a shell on demand" command. So `use git`
would give you something that's about 90% of gitsh, but equally `use apt-get`
would do the same thing for apt and so on.

But perhaps we're getting a little bit carried away here, for a couple of
keystrokes :-)

~~~
jdp
It already exists: [http://defunkt.io/repl/](http://defunkt.io/repl/).
Installing it and running `repl git` will put you into a git REPL.

~~~
stdbrouw
Thanks!

------
platinumdragon
It looks nice with the syntax coloring, and it's obvious a good amount of work
went into it, but I personally don't see a clear benefit to altering my
workflow to save what appears to literally be a couple of characters over a
transaction.

What might be interesting is being able to import and export configurations to
standardize git usage across multi-coder projects?

------
mateuszf
I see one problem with it .. how do I launch vim and other shell commands?

ctrl+z and using other terminals is ok, but it's not the same thing.

------
captn3m0
Another similar project (which I use) is scm breeze, which sets up tons of
useful aliases for various git commands. It gives you much cleaner git status
and log outputs, which allows you do things like `ga 1 3 5` to add files
numbered 1,3,5 to the index without typing in file names.

[1]:
[https://github.com/ndbroadbent/scm_breeze](https://github.com/ndbroadbent/scm_breeze)

------
xiaq
Interesting, but if I were the author I would definitely avoid the name
"gitsh" since some googling reveals there have been prior arts under exactly
the same name:
[https://github.com/caglar/gitsh](https://github.com/caglar/gitsh)
[https://gist.github.com/aristus/2304335](https://gist.github.com/aristus/2304335)

------
Bjoern
The only thing which I personally found interesting was the empty enter
command shows git status.

Here is something like that for zsh in case you need it.

[https://gist.github.com/anonymous/0aa22dc97ef832f88026](https://gist.github.com/anonymous/0aa22dc97ef832f88026)

------
Myrmornis

      Of all the Git commands, I find myself using git status most often
    

I literally never use status. It's faster to use a shell prompt that displays
uncommitted / untracked files.

------
madlee
I can definitely see myself using this. I generally have one terminal tab open
just for git anyways, so this would fold into my workflow nicely.

------
ktzar
Nothing that a couple of aliases can't do...

~~~
kaishin
It's not just about typing less, it's a whole UNIX philosophy of having
dedicated shells for programs that are complex enough for subcommands.

------
andyhmltn
Seems pretty good! Would love to use it but it's giving me an error about not
having >Ruby 2.0 (I use RVM)

~~~
gbrck
We were trying to avoid depending on RVM Rubies, because they get moved and
deleted a lot, and that shouldn't stop our dev tools from working.

If you're on OS X, and installed via Homebrew, then the installer should have
detected that system Ruby was too old and installed Ruby 2.0 from Homebrew for
you.

If you're not on OS X, you'll need to either install Ruby 2.0 or later before
installing gitsh, or if you want to work around our RVM avoidance, you can
force the installer to use your current RVM Ruby: `RUBY=$(which ruby)
./configure`

~~~
andyhmltn
Thanks! I managed to get it to work by running `ln -s $(which ruby)
/usr/lib/ruby` since nothing else on the system uses ruby

------
JBiserkov
Cool.

What about Windows?

