- 23 2月, 2017 3 次提交
-
-
由 Douwe Maan 提交于
-
由 Douwe Maan 提交于
-
由 Douwe Maan 提交于
-
- 22 2月, 2017 1 次提交
-
-
由 Douwe Maan 提交于
-
- 14 2月, 2017 1 次提交
-
-
由 Robert Speicher 提交于
-
- 11 2月, 2017 3 次提交
-
-
由 Robert Speicher 提交于
-
由 Robert Speicher 提交于
-
由 Robert Speicher 提交于
This is a little too picky, even for us.
-
- 10 2月, 2017 1 次提交
-
-
由 Robert Speicher 提交于
-
- 07 2月, 2017 1 次提交
-
-
由 Z.J. van de Weg 提交于
-
- 03 2月, 2017 1 次提交
-
-
由 Mike Greiling 提交于
-
- 11 1月, 2017 2 次提交
-
-
由 Grzegorz Bizon 提交于
-
由 Mike Greiling 提交于
-
- 17 12月, 2016 1 次提交
-
-
由 Rydkin Maxim 提交于
-
- 20 10月, 2016 1 次提交
-
-
由 Adam Niedzielski 提交于
We have to use the lowest common denominator to check the supported syntax and in our case it is Ruby 2.1. Please note that it will not help with unsupported syntax in HAML files because they are not checked by Rubocop.
-
- 04 10月, 2016 1 次提交
-
-
由 Robert Speicher 提交于
`Style/VariableNumber` is explicitly disabled because I don't think we care if we name a variable `var_1` or `var1`.
-
- 03 10月, 2016 1 次提交
-
-
由 Robert Speicher 提交于
-
- 21 9月, 2016 1 次提交
-
-
由 Robert Speicher 提交于
This reverts commit 70faf5fd, reversing changes made to 2307eb84.
-
- 16 9月, 2016 1 次提交
-
-
由 Robert Speicher 提交于
-
- 02 9月, 2016 1 次提交
-
-
由 Z.J. van de Weg 提交于
-
- 06 8月, 2016 3 次提交
-
-
由 Gabriel Mazetto 提交于
-
由 Gabriel Mazetto 提交于
-
由 Gabriel Mazetto 提交于
-
- 03 8月, 2016 1 次提交
-
-
由 Grzegorz Bizon 提交于
-
- 20 7月, 2016 1 次提交
-
-
由 Grzegorz Bizon 提交于
Avoid multi-line ?: (the ternary operator). Use if/unless instead. See #17478
-
- 19 7月, 2016 1 次提交
-
-
由 Grzegorz Bizon 提交于
This enables following cops: Check for useless access modifiers Lint/UselessAccessModifier Checks for attempts to use `private` or `protected` to set the visibility of a class method, which does not work. Lint/IneffectiveAccessModifier This also disables two false possitives in concerns.
-
- 14 7月, 2016 3 次提交
-
-
由 Connor Shea 提交于
-
由 Connor Shea 提交于
-
- 08 7月, 2016 1 次提交
-
-
由 Grzegorz Bizon 提交于
-
- 02 7月, 2016 1 次提交
-
-
由 Grzegorz Bizon 提交于
-
- 30 6月, 2016 1 次提交
-
-
由 Grzegorz Bizon 提交于
-
- 29 6月, 2016 3 次提交
-
-
由 Grzegorz Bizon 提交于
-
由 Grzegorz Bizon 提交于
-
由 Yorick Peterse 提交于
There are currently two cops for this: * Migration/AddIndex: checks if indexes are added concurrently * Migration/ColumnWithDefault: checks if columns with default values are added in a concurrent manner Both cops are fairly simple and make no attempt at correcting the code as this is quite hard to do (e.g. modifications may need to be applied in various places in the same file). They however should provide enough to catch people ignoring the comments in generated migrations telling them to use add_concurrent_index or add_column_with_default.
-
- 16 6月, 2016 2 次提交
-
-
由 James Lopez 提交于
This reverts commit 13e37a3e.
-
由 James Lopez 提交于
-
- 10 6月, 2016 1 次提交
-
-
由 Grzegorz Bizon 提交于
See #17478
-
- 09 6月, 2016 1 次提交
-
-
由 Sean McGivern 提交于
Migrations shouldn't fail RuboCop checks - especially lint checks, such as the nested method check. To avoid changing code in existing migrations, add the magic comment to the top of each of them to skip that file.
-
- 05 6月, 2016 1 次提交
-
-
由 Grzegorz Bizon 提交于
-