4 ms·

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

.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. There is talk about more general solutions here: https://groups.google.com/d/msg/rubyonrails-core/N2EFnf6X_i4/DeXxUsVCRJIJ https://groups.google.com/d/msg/rubyonrails-core/N2EFnf6X_i4...

Xylakant 14y ago
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$
- Hello71 14y ago
  That doesn't stop you from accidentally pushing it to GitHub though.
  - Xylakant 14y ago
    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.

Xylakant 14y ago

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$

Hello71 14y ago
That doesn't stop you from accidentally pushing it to GitHub though.
- Xylakant 14y ago
  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.