Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Browse files

Ignore /bin on new apps

  • Loading branch information...
commit 35c554f0bf518e1068e79002a462c3deba649e9b 1 parent a562f9f
@josevalim josevalim authored
Showing with 4 additions and 3 deletions.
  1. +4 −3 railties/lib/rails/generators/rails/app/templates/gitignore
7 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
-# Ignore the default SQLite database.
+# Ignore the default SQLite database
-# Ignore all logfiles and tempfiles.
+# Ignore all logfiles and tempfiles

3 comments on commit 35c554f


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.


@jeremy : :+1:
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.
Something went wrong with that request. Please try again.