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
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?
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?
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.
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.
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'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'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".
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:
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.
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):
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
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...
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".
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.
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:
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)
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:
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.