Saturday, June 28, 2008

Git tricks I've been using a lot

  • git add --patch

    Incredibly helpful for splitting up your patches into atomic commits.

    I use this like mad when I've made a few different types of changes between committing. (e.g. I find something that needs refactoring in the middle of adding a feature)

    For hairier tasks, don't forget it's older brother, git add --interactive, which launches a file manager shell with more options and better status info

  • git stash apply

    Git stash is a wonderful thing, but people often don't realize that the stash is a stack, not just a single object.

    Using apply with an optional ref argument, you can pop things off the stack that date from before the most recent stash.

    I use this as a whole project undo/redo for things not worth creating a branch for

  • git rebase --interactive

    Oh the power. If you pass the right revisions into git rebase --interactive, you can essentially go back and edit every single commit made in the repo.

    For extra fun, try nonlinear editing or cross-branch interactive rebasing.

    My primary use for this is to squash commits into useful units of functionality, particularly when updating a production branch or the equivalent.

    Caution: if you're publishing your changes to other people, using this can really piss them off. You can also drastically break your repo, so make sure you know what you're doing, or try it on a fresh clone

  • git checkout -b branch_name remote/branch

    This is an interesting trick: you can create a local branch named something different than a remote branch, and set it to track the remote. Makes git pull work without having to specify a remote and branch to merge.

  • git diff -Sstr

    This lets you pull out a change that relates to the string. If you want to see whole patches, play with --pickaxe-all, and for POSIX regex support use --pickaxe-regex.

    Useful if you ever want to see who's using that bad idiom that you want to crush out of existence, or if you need to go back and find a chunk of lost code.

Thursday, June 5, 2008

Why you should always use SSH keys, not passwords

There are three main reasons for using SSH keys over passwords:

  • Security

    Since SSH keys are stored on your computer and never go over the wire, they are inherently more secure than passwords. Even if you pick a terrible passphrase for your SSH keys (or none at all), an attacker still has to get ahold of that key (barring someone patching your random number generator to return one of 2^10 numbers...)

  • Segmentation

    With passwords, if everyone needs access to an account on one of your servers, then everyone has to know the same password. If one of your coworkers goes insane, you have to change the password (and probably a lot more than one) whereas with SSH keys, you just remove their key from the authorized_keys file and they're gone, nobody else has to worry about it.

    Similarly, if people need access to some accounts and not others, you can segment access with keys much more easily than with passwords

  • Speed

    Entering passwords gets old really quick. With the superb ssh-agent in use, you shouldn't ever have to do that, and as long as you remember to lock your computer when you leave it, you're as secure as if you were typing your password in every time