Permalink
Browse files

Ignore /bin on new apps

  • Loading branch information...
1 parent a562f9f commit 35c554f0bf518e1068e79002a462c3deba649e9b @josevalim josevalim committed Dec 22, 2012
Showing with 4 additions and 3 deletions.
  1. +4 −3 railties/lib/rails/generators/rails/app/templates/gitignore
@@ -4,13 +4,14 @@
# or operating system, you probably want to add a global ignore instead:
# git config --global core.excludesfile '~/.gitignore_global'
-# Ignore bundler config
+# Ignore bundler related files
/.bundle
+/bin
-# Ignore the default SQLite database.
+# Ignore the default SQLite database
/db/*.sqlite3
/db/*.sqlite3-journal
-# Ignore all logfiles and tempfiles.
+# Ignore all logfiles and tempfiles
/log/*.log
/tmp

3 comments on commit 35c554f

Owner

jeremy replied Dec 22, 2012

We'll want to encourage folks to check in their executables. That ensures the executables are available on all git clones without needing each person (or deploy scripts) to provide the correct --binstubs --shebang options to get a working app.

Contributor

nicolasblanco replied Dec 22, 2012

@jeremy : 👍
I aso encourage devs to check in binstubs.

You should not encourage people to check in binaries. As I said here things that can be generated on the fly (assets, environment config files, binaries) generally shouldn't be checked into the repository.

By checking in binaries you're now telling git: I want to be the gatekeeper to any change in this file. If it's going in bin/ it's most likely already version controlled in some other repository (a gem?). If it's not version controlled by some other repository and is executable then why isn't it in scripts/?

If the problem is "ensure the executables are available on all git clones [...] to get a working app" then the solution is having --binstubs --shebang be a part of your build process.

Please sign in to comment.