I forked Nicolas Gallagher's dotfiles, and merged them with Zach Holman's dotfiles which is a more component based approach.

The installation step requires the XCode Command Line Tools and may overwrite existing dotfiles in your HOME and .vim directories.

$ bash -c "$(curl -fsSL raw.github.com/michaelxor/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 bin/dotfiles script.

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, Node packages, or Python packages.

Run the dotfiles command:

$ dotfiles

Options:

Each component has an associated requirements.txt file. Add or remove packages from these files and the associated package manager will install and update accordingly.

Any file named *.bash inside of a component folder will be automatically picked up loaded into your environment. I'm following Zach Holman's approach as follows:

• component/*.bash: Any files ending in .bash get loaded into your environment.
• component/path.bash: Any file named path.bash is loaded first and is expected to setup $PATH or similar.
• component/completion.bash: Any file named completion.bash is loaded last and is expected to setup autocomplete.
• component/*.symlink: Will be symlinked to your home directory minus the .symlink suffix.

Homebrew is recommended as most of the other components depend on utilities installed during this step.

• GNU core utilities
• git
• svn
• ack
• bash (latest version)
• bash-completion
• ffmpeg
• graphicsmagick
• jpeg
• macvim
• optipng
• phantomjs
• rsync (latest version, rather than the out-dated OS X installation)
• tree
• wget
• grc

Homebrew also installs each of the following unless their respective component is suppressed:

• cask
• node
• python
• python3

Homebrew Cask can install Mac GUI applications. Apps installed this way are collected in /opt/homebrew-cask/Caskroom instead of /Applications or ~/Applications. If Alfred is installed, the Caskroom directory is automatically linked to Alfred so these apps will be indexed.

• google-chrome
• google-chrome-canary
• firefox
• firefox-aurora
• alfred
• dropbox
• droplr
• iterm2
• dash
• sublime-text3
• sequel-pro
• skype

As well as some really handy Quick Look Plugins from Sindre Sorhus.

• qlcolorcode
• qlstephen
• qlmarkdown
• quicklook-json
• qlprettypatch
• quicklook-csv
• betterzipql
• webp-quicklook
• suspicious-package

Node packages are installed via npm. The packages in this list are installed globally, so you may want to keep this list to things you plan on using from the command line.

• bower
• gify
• grunt-cli
• jshint
• karma
• yo

The latest Python 2.x and 3.x branches are installed via Homebrew, and they are bundled with pip. virtualenv, virtualenv-clone, and pew are installed globally via pip. The contents of requirements.txt are then installed via pip to a new clean virtualenv.

For those unfamiliar with pew, it is an alternative to virtualenvwrapper for managing multiple virtualenvs. It also provides an alternative method to activate virtual environments instead of the traditional activate/deactivate.

pip and pew are both configured to use ~/.virtualenvs as the default for new virtual environments.

• virtualenv
• virtualenv-clone
• pew

These are installed into your default virtualenv:

• django
• ipython

Functions

$ check_virtualenv

Checks the current directory for existence of a .venv file. If it exists and its contents name an exsiting virtualenv, that virtualenv will be activated

$ venv_cd <path>

Performs a cd and then calls check_virtualenv

The latest stable RVM is installed with the latest Ruby. The contents of requirements.txt are assumed to be gems and are installed to the default rvm environment.

• sass

The latest PHP 5.5.x and 5.6.x branches are installed. php-versions is included to make switching between multiple versions of PHP easier.

• php56
• php56-xdebug
• php56-mcrypt
• php56-memcached
• php55
• php55-xdebug
• php55-mcrypt
• php55-memcached
• php-version
• phpunit

Functions

$ switch_php <version>

Updates the command line PHP and PEAR commands as well as the currently loaded apache php module.

$ getcomposer [<dir>]

Installs composer to the current working directory, or to the directory specified if it exists.

• ctrlp.vim
• html5.vim
• mustache.vim
• syntastic
• vim-colors-solarized
• vim-git
• vim-haml
• vim-javascript
• vim-less
• vim-markdown
• vim-pathogen

Custom OS X settings can be applied during the dotfiles process. They can also be applied independently by running the following command:

If an environment variable called $MACHINE_NAME is present, your machine will be renamed to the value stored in this variable.

$ osxdefaults

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:

$ backup

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.

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:

When your current working directory is an SVN repository, the prompt will display the checked-out branch's name. The state of the working tree is reflected in the following way:

Further details are in the bash_prompt file.

Screenshot:

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 .vimrc.

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 bash_profile.

Here is an example ~/.bash_profile.local:

# 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="Michael Hofer"
GIT_AUTHOR_EMAIL="[email protected]"
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.

If your Homebrew installation is not in /usr/local then you must prepend your custom installation's bin to the PATH in a file called ~/.dotfilesrc:

# Add `brew` command's custom location to PATH
PATH="/opt/acme/bin:$PATH"

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

• @mathiasbynens (Mathias Bynens) https://github.com/mathiasbynens/dotfiles
• @tejr (Tom Ryder) https://github.com/tejr/dotfiles
• @gf3 (Gianni Chiappetta) https://github.com/gf3/dotfiles
• @cowboy (Ben Alman) https://github.com/cowboy/dotfiles
• @alrra (Cãtãlin Mariş) https://github.com/alrra/dotfiles
• @holman (Zach Holman) https://github.com/holman/dotfiles
• @sindresorhus (Sindre Sorhus) https://github.com/sindresorhus/quick-look-plugins