Dotfiles (Nicolas Gallagher)
My OS X dotfiles.
How to install
The installation step requires the XCode Command Line
Tools and may overwrite existing
dotfiles in your HOME and
$ bash -c "$(curl -fsSL raw.github.com/necolas/dotfiles/master/bin/dotfiles)"
N.B. If you wish to fork this project and maintain your own dotfiles, you must
substitute my username for your own in the above command and the 2 variables
found at the top of the
How to update
You should run the update when:
- You make a change to
~/.dotfiles/git/gitconfig(the only file that is copied rather than symlinked).
- You want to pull changes from the remote repository.
- You want to update Homebrew formulae and Node packages.
Run the dotfiles command:
||List of additional applications to install|
||Suppress package updates|
||Suppress pulling from the remote repository|
Automatic software installation
- GNU core utilities
- bash (latest version)
- rsync (latest version, rather than the out-dated OS X installation)
Custom OS X defaults
Custom OS X settings can be applied during the
dotfiles process. They can
also be applied independently by running the following command:
Bootable backup-drive script
These dotfiles include a script that uses
rsync to incrementally back up your
data to an external, bootable clone of your computer's internal drive. First,
make sure that the value of
DST in the
bin/backup script matches the name
of your backup-drive. Then run the following command:
For more information on how to setup your backup-drive, please read the preparatory steps in this post on creating a Mac OS X bootable backup drive.
Custom bash prompt
I use a custom bash prompt based on the Solarized color palette and influenced by @gf3's and @cowboy's custom prompts. For best results, you should install iTerm2 and import Solarized Dark.itermcolors.
When your current working directory is a Git repository, the prompt will display the checked-out branch's name (and failing that, the commit SHA that HEAD is pointing to). The state of the working tree is reflected in the following way:
||Uncommitted changes in the index|
Further details are in the
Local/private Bash and Vim configuration
Any special-case Vim directives local to a machine should be stored in a
~/.vimrc.local file on that machine. The directives will then be automatically
imported into your master
Any private and custom Bash commands and configuration should be placed in a
~/.bash_profile.local file. This file will not be under version control or
committed to a public repository. If
~/.bash_profile.local exists, it will be
sourced for inclusion in
Here is an example
# PATH exports PATH=$PATH:~/.gem/ruby/1.8/bin export PATH # Git credentials # Not under version control to prevent people from # accidentally committing with your details GIT_AUTHOR_NAME="Nicolas Gallagher" GIT_AUTHOR_EMAIL="email@example.com" GIT_COMMITTER_NAME="$GIT_AUTHOR_NAME" GIT_COMMITTER_EMAIL="$GIT_AUTHOR_EMAIL" # Set the credentials (modifies ~/.gitconfig) git config --global user.name "$GIT_AUTHOR_NAME" git config --global user.email "$GIT_AUTHOR_EMAIL" # Aliases alias code="cd ~/Code"
N.B. Because the
git/gitconfig file is copied to
~/.gitconfig, any private
git configuration specified in
~/.bash_profile.local will not be committed to
your dotfiles repository.
Custom location for Homebrew installation
If your Homebrew installation is not in
/usr/local then you must prepend your
bin to the PATH in a file called
# Add `brew` command's custom location to PATH PATH="/opt/acme/bin:$PATH"
Adding new git submodules
If you want to add more git submodules, e.g., Vim plugins to be managed by pathogen, then follow these steps while in the root of the superproject.
# Add the new submodule git submodule add https://example.com/remote/path/to/repo.git vim/bundle/one-submodule # Initialize and clone the submodule git submodule update --init # Stage the changes git add vim/bundle/one-submodule # Commit the changes git commit -m "Add a new submodule: one-submodule"
Updating git submodules
Updating individual submodules within the superproject:
# Change to the submodule directory cd vim/bundle/one-submodule # Checkout the desired branch (of the submodule) git checkout master # Pull from the tip of master (of the submodule - could be any sha or pointer) git pull origin master # Go back to main dotfiles repo root cd ../../.. # Stage the submodule changes git add vim/bundle/one-submodule # Commit the submodule changes git commit -m "Update submodule 'one-submodule' to the latest version" # Push to a remote repository git push origin master
Now, if anyone updates their local repository from the remote repository, then
git submodule update will update the submodules (that have been
initialized) in their local repository. N.B This will wipe away any local
changes made to those submodules.
Inspiration and code was taken from many sources, including: