While you can make aliases per project, I always make ’em global via git config --global alias or by editing ~/.gitconfig.

Here’s the pattern to make an alias using git config:

git config --global alias.aliascommand

For example, I use git statusa lot, so a shorter alias would be nice:

git config --global alias.s status

This will add the following to your ~/.gitconfig file:

[alias]
s = status

Now if I type git s I get the same output as git status. Of course you can always open ~/.gitconfig in a text editor and add s = status manually under the [alias] section. Here are some other basic aliases I’m using (more exciting ones to follow):

Some basic git command aliases

Alias

Command

git s

git status

git a

!git add . && git status

git au

!git add -u && git status

git aa

!git add . && git add -u && git status

git c

git commit

git cm

git commit -m

git spull

git svn rebase

git spush

git svn dcommit

A couple of things to note:

If you’re using git config you’ll need to quote commands that are more than one word, e.g.

If the command takes input, like the commit message for git commit -m, as long as -m is last you’re fine e.g. with the above aliases git cm "initial commit" is the same as git commit -m "initial commit"

While the previous alias solved my first three needs, I still sometimes want to see what changed and by how much. This next command gives the same info as the default git log, but adds a list of each file changed per commit, and an indication of how much each file changed. I alias it to git ll.

We can improve on this with a couple of config tweaks. To add soft wrapping to git diffs we can add pager = less -r under [core] in your .gitconfig, e.g. by using git config --global core.pager less -r.

Changing the pager settings for a soft wrapped diff — getting better

To change from per-line to per-word diffs, we can use the flags --word-diff=color or --color-words. The easiest way is to make an alias like git config --global alias.d = diff --color-words.

Soft wrapping plus OMG THIS IS AWESOME --color-words

While --color-words automatically turns on diff coloring, I’ve also got the following in .gitconfig under [color]:

Amazon just announced Kindle Format 8, supporting HTML5 and CSS3! Yay! But closer inspection reveals they’re only supporting the marketing version of “HTML5” and “CSS3”. Boo! Won’t someone just give us the web stack for ebooks already?

Is CSS Lint’s “Don’t use IDs in selectors” suggestion just crazy talk? While some are using this suggestion’s supposed ‘obviously bad’-ness as a reason to reject CSS Lint out of hand, it’s more valuable to actually examine the why behind this suggestion. The reasons may surprise you…

I’ve written an article on extending HTML5 with microformats for HTML5Doctor.com:

HTML5 contains a bunch of new semantic goodness, but sometimes we need more semantics than what’s available. This is the first article in a series looking at various ways to extend HTML5 — first up, microformats.

As with the CSS selectors article, I wanted a summary of animatable CSS properties, so I’ve made a copy of the W3C one and reordered/tweaked it a little. It’s now referenced from the Mozilla Developer Network wiki, so I guess I better keep it updated ;)

The <ruby>, <rt> and <rp> elements allow us to add ‘ruby’ phonetic annotations in languages like Japanese and Chinese. Despite the terrors of internationalisation and patchy browser support — with a little fiddling and a lot of caution — this sexy threesome with adorable accents are ready to use now.

While many HTML4 elements have been brought into HTML5 essentially unchanged, several historically presentational ones have been given semantic meanings. Let’s look at <i> and <b> and compare them to the semantic stalwarts <em> and <strong>.

Firefox breaks HTML5-style block-level links (a link wrapping block not inline elements) when they contain HTML5 semantic elements. The link and first contained element are closed, and multiple new links are inserted. Wrapping the link content in a <div> can help, but the resultant behavior may still appear due to another bug (the infamous packet boundary bug).

A look at the differences between a basic HTML 4 and XHTML 1 page and the same page using HTML5’s structural elements, plus the CSS/JS required for support in browsers, adding HTML5’s semantics via <div class=""> to get around ‘the IE problem’, and a summary of why you should be thinking about HTML5 now.

Updated!An in-depth look at why the W3C Validator lists charset warnings & errors when using the HTML5 doctype, and what you should do about it. This bug has been fixed! <meta charset="utf-8"> is good to go.