Working with git? These aliases will save you hours | Hacker News Reader

Working with git? These aliases will save you hours

catonmat.net

112 pointspkrumins56 comments

Personally, I find these aliases a bit too terse.

Aliases are important for enhanced productivity, but shell aliases are too much. I find these git aliases much more comfortable:

    alias.st=status
    alias.co=checkout
    alias.com=checkout master
    alias.cam=commit -a -m
    alias.cm=commit -m
    alias.br=branch

push, pull, merge, rebase and the rest are infrequently used, so I don't alias them at all. Using shell aliases (as opposed to git aliases) is unjustified IMO, as is the horrible

    alias g='git'

which gives me the creeps.

just another one

alias grm="git status | grep deleted | awk '{print \$3}' | xargs git rm"

I have a similar thing in my .gitconfig:

    [alias]
      rm-a  = "!git ls-files -z --deleted | xargs -0 git rm"

Why not add -u?

Why do shell aliases make you uncomfortable? If we are talking about your personal machine, and not a server where another user can be bitten by not understanding your personal alias preferences, what could the harm be?

I use the g=git alias :) Are there any negative consequences I should be aware of?

Tab-completion via git-completion.bash won't work. I think you can add the following at the end of git-completion.bash to fix it, though:

  complete -o bashdefault -o default -o nospace -F _git g 2>/dev/null \
    || complete -o default -o nospace -F _git g

Tab-completion on my zsh setup still works. I'm not sure why.

Mercurial accepts unique prefixes to commands by default. (For example, hg me is the same as hg merge.) Hg wins again!

I quite agree. Here are my git aliases:

        stat = status
        stta = status
        satt = status
        tat = status
        co = checkout
        fo = fetch origin
        ff = merge --ff-only
        ffo = merge --ff-only @{u}
        po = push origin HEAD

I'm a bit skeptical on the usefulness of this. As far as my coder nose goes, this has a really really bad smell and if I saw this sort of stuff in my codebase I would feel an urge to punch somebody.

From a productivity point of view, since this is presumably used by developers, we can safely assume these are people who spend at least 10 hours a day typing (coding, internet etc.). Most of our lives are spend behind a keyboard yes?

That being the case, we can safely assume that most of us are pretty good typists. Even a marginally good typist can punch the keyboard at 60 words per minute. Considering the average English word length of 5.7 characters that gives us a speed of 342 characters per minute, or 5.7 per second.

Do you really really need to increase your mental load for translating acronyms/abbreviations into words in order to save fractions of a second? Really?

For some long and complex git commands I have aliases, also for command line options that I always want to provide. My ~/.gitconfig therefore is quite extensive.

But I agree that using aliases for trivial, short commands such as these doesn't really help. Remembering the alias is more work then just typing the whole command.

Edit: why is jacques_chester's reply to this post killed!?

While I agree that aliasing checkout just does not make sense given how often it is used, and (at least in my opinion) aliasing push to be easier to accidentally invoke is a bad decision, given that it modifies upstream, making the more used commands shorter is a nice to have feature.

I myself only use couple aliases, for the most used commands - 'gita' for add, 'gits' for status, 'gitd' for diff. Those are the things I use A LOT (especially when preparing a commit), and shaving off couple characters there does pay off. And no, I don't feel that these muscle-memory level shortcuts add any mental load.

I only alias git commands that have typical flags that I use over and over. For example, "git log --pretty=oneline -10" is aliased to gitlog.

Basically, any command that I have to even passively think about the parameters which is used often enough gets its own alias. This does not include commands like "git add" because I don't even think about parameters when I'm typing it out. Having to remember that I set ga to "git add" adds more work than I'm doing now.

Thank you! Easily the only sane comment about aliasing.

I am willing to believe that aliases like 'ga' and 'gp' would actually increase productivity if all you did all day long was manipulate a git repository or you had some physical disability in which it was actually difficult to type on a keyboard, but I mean, using my source control tool is such a small piece of the larger initiative I take on day in and day out, that in the end, the extra keystrokes aren't going to have any meaningful impact on the amount of value I add to the projects I work on.

There's also the issue with portability. You have to be able to bring those aliases with you anywhere you go. A great example I heard about was at a meetup once where a guy tried to give a talk on git and because he wasn't using his machine, that talk was almost worthless because he kept typing his precious little aliases and, arguably, didn't really know how to use the tool he was trying to demonstrate.

"The extra keystrokes aren't going to have any meaningful impact on the amount of value I add to the projects I work on."

Nor will removing those keystrokes have a negative impact on the value you add.

Fear of forgetting the original commands is a reasonable argument against using aliases. It's very similar to the argument against using vim plugins for fear that you won't know how to use vi on servers or other peoples' machines. Nonetheless, most people use the plugins on their development machines which they feel make them the most productive in their day to day work. Same thing for aliases.

"It's very similar to the argument against using vim plugins for fear that you won't know how to use vi on servers or other peoples' machines."

Using vim plugins on your development machine should only add value to your standard commands. You still use standard vim commands to move around and manipulate text. And noone expects you to modify whole application on server, so you don't need those extra plugins for project manipulation, code completion (you still can type, right?) or highlighting

I probably use 'git checkout' 50-100 times a day, which I imagine is typical when you're working on several branches at once.

How many times do you type "git status" in your typical workday?

Dozens, sometimes a hundred.

So I use similar shortcuts and like them. There's nothing wrong with creating shortcuts for almost everything. Some shortcuts I remember better than others; the ones I don't remember I just type out in full, and eventually I either get inspired to remember the shortcut or the shortcut evolves out of my config file.

I use the trick of aliasing "git" to "g", which I learned from Howard Yeh:

http://www.metacircus.com/hacking/2011/02/18/play-git-like-a...

That's an easy one.

Not nearly as often as I type actual code or need to think about something. Plus in normal usage it's "g<up arrow>" since I have shell history searching.

Yes, these aliases really help. Version control schemes like git reward frequent commits. Anything that lowers the barrier to a commit is good.

Especially when you're under hard time pressure, commits can often fall by the wayside, unless they're super easy (read: need very few keystrokes).

My pet alias:

    cm='git commit -m "#-checkpoint-" --edit'

I commit all the time that way; "cm -a", x, ZZ

I'm not really a very fast typist, or at least, I often make typing errors (Which is OK, since programming really has very little to do with typing and we have good IDEs, so errors very rarely persists for more than a few seconds).

I frequently get the order of the left hand letters of "status" wrong, or sometime SVN muslememory kicks in, and I just write "stat". Parsing the error message on the screen is orders of magnitude slower that just getting it right. "gs" would greatly decrease my risk of getting it wrong.

if I saw this sort of stuff in my codebase...

Your codebase should be optimized for reading. Your aliases file should be optimized for very, very frequent typing.

These are different goals, so naturally the solutions look different.

Typing on the command line is not like typing in a code file: it's perhaps the least forgiving environment for typos, and tiny mistakes can have huge consequences. A good typist can re-type the correct text after the command finishes--maybe a moment too late. A good coder takes pains to avoid the mistake in the first place.

tiny mistakes can have huge consequences

Yes, that's why we are not discussing the creation of easily typed aliases for "rm -rf". That would be bad.

Instead we are discussing aliases for a bunch of fairly innocent Git commands, most of which are reversible in case of catastrophic accident.

I admit that I do have a four-character abbreviation for "git reset --hard". Maybe that will burn me one day, though I rarely pile up so many uncommitted changes that I have much at risk. Or maybe I'll make that shortcut a little longer.

It won't burn you, the commits are still around until you get garbage collected.

I don't understand why these examples even need to be optimised, just keep a pinkie finger hovered over tab and leverage bash's autocomplete :|

The mental load only lasts a day or two. After that it's all muscle memory.

I'm still not sold on pair programming, but one of the benefits is that you actually get to see how much time you can waste mistyping "git stauts" three times.

Of course, it's not "git merge" or "git status" or "git log" you want to alias, necessarily--it's "git merge --no-ff", "git status -sb", or "git log --oneline --decorate".

I think more can be saved by learning to use the shell (e.g. bash) better.

For instance, since the shell has command history that persists between sessions, once you've run e.g. "git push" once, you can run it again by typing e.g. "^R pu" (including the space to make it more unique). That's more keypresses than just "gp", but way clearer and more portable since it will work wherever you have Bash, not just where your particular aliases are installed.

Interactive history search (^R) in Bash (and IPython) so awesome, it can't be overstated. I've become so addicted to it that I start almost any command with ^R now. For most of them, I've got them somewhere in history - and only if it doesn't find anything, I ^C and type manually.

I use shell history all the time, but I don't personally find it useful to use for really common operations. I agree with the OP that commands that you execute 10's or 100's of times a day should be made as short as possible and they'll be part of muscle memory.

You can't rely on muscle memory for history commands as you always need to pause and verify that history found what you were expecting it to find. If your history looked like this (real shell history for me):

    git push
    ssh ec2-75-101-198-99.compute-1.amazonaws.com

the ^R would find the ssh command first, so you can't trust that "^Rpu" will always find the command so muscle memory can't set in and will slow you down

I love ^R

But make sure you've found the command you really thought you were looking for before mashing the return key. Sometimes my muscle memory is a bit too fast...

If you love ^R, you'll also love http://www.catonmat.net/blog/the-definitive-guide-to-bash-co...

  "\e[A": history-search-backward
  "\e[B": history-search-forward

In .inputrc lets me just start typing a command and then press the up arrow to search the history, no need for ^R.

You can define custom auto-completions for bash as well. If you're running Ubuntu, it ships with a default set of auto-completions that cover git, svn and cvs commands.

Try it for yourself: type "git stat<Tab>" and it'll autocomplete to "git status".

Cool, where's the config file for that?

Install bash_completion (yum/port install bash_completion).

Then in your bash .profile: source /etc/bash_completion

If you really want to save time and keystrokes, use git-sh so that you don't even need to type (or alias) git itself. You can still run all your normal shell commands with it too.

https://github.com/rtomayko/git-sh

There's a list of short aliases enabled in git-sh by default here:

http://rtomayko.github.com/git-sh/

If you're using ZSH, Oh-my-zsh has a very nice git plugin https://github.com/robbyrussell/oh-my-zsh/blob/master/plugin...

I'm totally fine with auto-completion, no need for aliases here though it might make sense if you are using the same longish command over and over again...

E.g. the following does the trick for tcsh, search the web for '<myfavshell> git completion' and you'll find your way:

set gitcmds= ( `ls /usr/local/bin/git-*|sed ’s/\/usr\/local\/bin\/git-//g’` ) complete git “p/1/($gitcmds)/” ‘n/branch/`git branch|cut -c 3-`/’ ‘n/co/`git branch|cut -c 3-`/’ ‘n/remote/(show add rm prune update)/’ ‘N/remote/`git remote`/’

I love shell aliases and have recently taken to aliasing as much stuff as possible. For example, I journal my thoughts on a more or less daily basis and I store the file in a git-tracked repo, so I have this alias:

  alias think="cd ~/Documents/docrepo && git pull && mvim personal/thoughts.htm"

When I want to think I just enter "think".

I also set up aliases for my most commonly worked on projects that cd into the correct folder, set the correct rvm version, etc.

I'm too scared to add -am to my commit alias but these are pretty reasonable in my opinion... Can't live without them, and have definitely convinced some others that this is the way to go. On another note, I can't wait until there is an actual GUI that makes these aliases obsolete by saving us even more time.

git st (status) git ct (commit) git br (banch) git co (checkout) git back (reset --hard) git last (log -1 head) git last2 (log -2 head)

I've aliased git to "g" in bash and set up aliases in my ~/.gitconfig [1].

Reducing "git" to "g" or "status" to "st" doesn't speed up my workflow much. The real gains come with aliasing something like this:

  git --no-pager log --oneline --graph -n 18 --decorate

[1] https://github.com/dave1010/scripts/blob/master/gitconfig

Agreed. What I would really like to see is alias' to handle git operations that you typically would have a slim chance of remembering on your own. For example, reverting changes: http://stackoverflow.com/questions/927358/git-undo-last-comm... http://stackoverflow.com/questions/348170/undo-git-add

Save me hours? Over a year maybe. Trust me, this isn't the biggest time suck I have. stares intently at HN

Posted a comment on the site, but to me the real win comes when you add grep to your aliases. That saves a ton of keystrokes, assuming you have deep directories in your project:

http://www.draconianoverlord.com/2010/03/04/git-config.html

I don't save time by having non-standard commands that aren't available on all of my machines.

If you use git-svn, this makes git svn dcommit -n actually useful to review what you are going to commit:

    [alias]
        svndiff = !"$(git svn dcommit -n | grep "diff-tree" | sed 's/diff-tree/git diff-tree --color=auto -p/')"

Not to mention editor/IDE integration that streamlines common workflows making the need to use the shell for git commands less likely

The big downside of these (for me) is that they don't let me use the great bash completion that git (optionally) provides.

They can!

  # Make git completion work with aliases
  complete -o default -o nospace -F _git_checkout gco
  complete -o default -o nospace -F _git_rebase grb
  complete -o default -o nospace -F _git_branch gbdf
  complete -o default -o nospace -F _git_branch gbd
  complete -o default -o nospace -F _git_diff gd
  complete -o default -o nospace -F _git_log gl
  complete -o default -o nospace -F _git_log glp

git aliases > bash aliases, since completion still works.

Here's mine: https://gist.github.com/916019

Reply on news.ycombinator.com