Working with git? These aliases will save you hours(catonmat.net)
catonmat.net
Working with git? These aliases will save you hours
http://www.catonmat.net/blog/git-aliases
62 comments
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 gTab-completion on my zsh setup still works. I'm not sure why.
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 HEADjust another one
alias grm="git status | grep deleted | awk '{print \$3}' | xargs git rm"
alias grm="git status | grep deleted | awk '{print \$3}' | xargs git rm"
Mercurial accepts unique prefixes to commands by default. (For example, hg me is the same as hg merge.) Hg wins again!
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?
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?
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.
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.
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 :|
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!?
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!?
[deleted]
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 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.
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.
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.
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
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.
The mental load only lasts a day or two. After that it's all muscle memory.
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.
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.
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".
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".
[deleted]
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).
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'
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.
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.
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.
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.
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):
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
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...
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
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.
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".
Try it for yourself: type "git stat<Tab>" and it'll autocomplete to "git status".
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
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/
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`/’
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:
I also set up aliases for my most commonly worked on projects that cd into the correct folder, set the correct rvm version, etc.
alias think="cd ~/Documents/docrepo && git pull && mvim personal/thoughts.htm"
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)
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:
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
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
[deleted]
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
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/')"[deleted]
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[deleted]
git aliases > bash aliases, since completion still works.
Here's mine: https://gist.github.com/916019
Here's mine: https://gist.github.com/916019
Aliases are important for enhanced productivity, but shell aliases are too much. I find these git aliases much more comfortable:
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
which gives me the creeps.