In this app's case the setup.rb is an ideal candidate for generating a new secret_token (and raising an exception on startup until you've generated a token).
I actually went through the setup.rb and was surprised they don't do it. Rails itself will raise the exception if the initializer does not exist IIRC, so just removing the file and .gitignoring it would do.
.gitignoring will hurt anybody deploying via git (e.g. heroku) in the absence of some ENV magic. It'd be fine to have the regenerated file checked into each user's repo as long as they have the good sense not to push that repo up to a public fork on github.
Neither of the solutions is actually beautiful, they all require some sort of deployment magic - env variables set, cap symlinking files or similar. What works for me probably doesn't work for you.
Btw: you can check the regenerated file into the repo, adding it to .gitignore just prevents you from accidentally adding it:
Last login: Tue Jan 15 17:07:14 on ttys005
Voice-of-Evening:~ fgilcher$ cd /tmp
Voice-of-Evening:tmp fgilcher$ git init test
Initialized empty Git repository in /private/tmp/test/.git/
Voice-of-Evening:tmp fgilcher$ cd test/
Voice-of-Evening:test fgilcher$ echo "README" >> .gitignore
Voice-of-Evening:test fgilcher$ touch README
Voice-of-Evening:test fgilcher$ git status
# On branch master
#
# Initial commit
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# .gitignore
nothing added to commit but untracked files present (use "git add" to track)
Voice-of-Evening:test fgilcher$ git add -f README
Voice-of-Evening:test fgilcher$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached <file>..." to unstage)
#
# new file: README
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# .gitignore
Voice-of-Evening:test fgilcher$
No, quite to the contrary: Once you do this, you'll push it in the next commit. But in the case of an OS app you'd probably want to create a private repo for the app since all your configuration would be public otherwise. If you deploy to heroku, you'll have at least one private git repo on heroku.
