My OS X dotfiles, based on necolas's amazing repo. Not much of a diff besides the emacs stuff.
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/senorflor/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 and Node packages.
Run the dotfiles command:
$ dotfiles
Options:
-h , --help |
Help |
-l , --list |
List of additional applications to install |
--no-packages |
Suppress package updates |
--no-sync |
Suppress pulling from the remote repository |
Homebrew formulae:
Node packages:
Vim plugins:
- ctrlp.vim
- html5.vim
- mustache.vim
- syntastic
- vim-colors-solarized
- vim-git
- vim-haml
- vim-javascript
- vim-less
- vim-markdown
- vim-pathogen
N.B. If your pre-existing Homebrew installation is not in /usr/local
then you
must prepend your custom installation's bin
to the PATH in
.bash_profile.local
:
# Add `brew` command's custom location to PATH
PATH="/opt/acme/bin:$PATH"
Custom OS X settings can be applied during the dotfiles
process. They can
also be applied independently by running the following command:
$ osxdefaults
These dotfiles include a script that will 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:
+ |
Uncommitted changes in the index |
! |
Unstaged changes |
? |
Untracked files |
$ |
Stashed files |
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 commands should be stored in a ~/.bash_profile.local
file. Any commands included in 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="Patrick Flor"
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"
# Export PhantomJS bin location for custom Homebrew directory
export PHANTOMJS_BIN="$(brew --prefix)/bin/phantomjs"
The git/gitconfig
file is copied to ~/.gitconfig
, so any private git
configuration specified in ~/.bash_profile.local
will not be committed to
your dotfiles repository.
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.
- @necolas (Nicolas Gallagher) https://github.com/necolas/dotfiles
- @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