Hacker News Reader

Comment by Swizec | Hacker News Reader

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?

View on HN

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 :|

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.

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'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".

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

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.

Reply on news.ycombinator.com