aboutsummaryrefslogtreecommitdiffstats
path: root/railties/lib/rails/commands/generate.rb
Commit message (Collapse)AuthorAgeFilesLines
* removes usage of Object#in? from the code base (the method remains defined ↵Xavier Noria2012-08-061-2/+1
| | | | | | | | | | | | | | | | | | | by Active Support) Selecting which key extensions to include in active_support/rails made apparent the systematic usage of Object#in? in the code base. After some discussion in https://github.com/rails/rails/commit/5ea6b0df9a36d033f21b52049426257a4637028d we decided to remove it and use plain Ruby, which seems enough for this particular idiom. In this commit the refactor has been made case by case. Sometimes include? is the natural alternative, others a simple || is the way you actually spell the condition in your head, others a case statement seems more appropriate. I have chosen the one I liked the most in each case.
* Refactor identifying generator's destination rootStefan Sprenger2011-05-271-5/+2
|
* Introducing engine commandsStefan Sprenger2011-05-261-1/+6
|
* Streamline generators initialization flow.José Valim2011-05-251-2/+0
|
* Remove `#among?` from Active SupportPrem Sichanugrist2011-04-131-1/+1
| | | | | | After a long list of discussion about the performance problem from using varargs and the reason that we can't find a great pair for it, it would be best to remove support for it for now. It will come back if we can find a good pair for it. For now, Bon Voyage, `#among?`.
* Change Object#either? to Object#among? -- thanks to @jamesarosen for the ↵David Heinemeier Hansson2011-04-121-1/+1
| | | | suggestion!
* Using Object#in? and Object#either? in various placesPrem Sichanugrist2011-04-111-1/+3
| | | | There're a lot of places in Rails source code which make a lot of sense to switching to Object#in? or Object#either? instead of using [].include?.
* remove executable permission from files that don't need it. [#4802 ↵rohit2010-06-201-0/+0
| | | | | | state:resolved] Signed-off-by: José Valim <jose.valim@gmail.com>
* Still copy application configuration to generator even if they are required ↵José Valim2010-06-021-0/+1
| | | | earlier. Also tidy up the guide a little bit.
* Add missing -h/--help flag to several rails command [#3909 status:resolved]Prem Sichanugrist2010-02-101-2/+2
| | | | Signed-off-by: José Valim <jose.valim@gmail.com>
* Automatically configure generators if application is defined.José Valim2010-01-291-1/+0
|
* No more hacks to ensure generators are executed inside Rails.root.José Valim2010-01-071-1/+1
|
* Refactor generators a little bit.José Valim2009-11-081-0/+3
| | | | Signed-off-by: Yehuda Katz <wycats@mobile-166-129-219-135.mycingular.net>
* Pass config.generators options along when RAILS_GENERATORS is set and show ↵José Valim2009-11-031-2/+0
| | | | | | --force-plural message just once. Signed-off-by: Jeremy Kemper <jeremy@bitsweat.net>
* script/generate should require environmentJoshua Peek2009-10-161-1/+0
|
* Use Rails.initialize! where we just want to run the initializers and aren't ↵Joshua Peek2009-10-161-1/+1
| | | | concerned about the config
* Have config/application.rb contain the application definition and require ↵Carl Lerche2009-10-151-1/+1
| | | | that file instead of config/boot.rb or config/environment.rb in script/*.
* Move railties/lib/* into railties/lib/*Yehuda Katz + Carl Lerche2009-09-241-0/+10