struys

(1) We definitely thought about implementing a search/auto-suggest for pre-commit. We'd love help from the community to build a solution for that. You can follow/add ideas on the v2 label - https://github.com/pre-commit/pre-commit/issues/10

For the time being our registry of available hooks is here: https://github.com/pre-commit/pre-commit.github.io/blob/real.... We use that file to generate this page - http://pre-commit.com/hooks.html. It's also available as json - http://pre-commit.com/all-hooks.json. If you create new hooks for pre-commit we'd love to get a pull request to add to all-repos.yaml.

It would be awesome to have `pre-commit search <keyword>` and `pre-commit add <hook-id>`.

(2) I think we could integrate with yeoman generators to provide the company wide requirements. It's really hard to make assumptions about the structure of a repo, often just knowing extensions is not enough to identify file types (e.g. tests, auto generated code). Generally we leave it up to the developer, we don't want to enforce too much.

We're definitely encouraging fixers over linters at Yelp. It's great to tell a developer "Hey you missed a semicolon" via jshint but it's much more useful to say "Hey you missed a semicolon, we fixed it and our change is unstaged, if you agree with our change add/commit" via fixmyjs. We'll be supporting fixmyjs really soon. We were blocked by https://github.com/jshint/fixmyjs/pull/99 and now we're just waiting for the next release.

If you're a python developer using our autopep8-wrapper (found in this repo - https://github.com/pre-commit/pre-commit-hooks) is really awesome. It fixes a lot of the simple pep8 issues.

It's a weird form of a package manager yeah. The hooks execute independently from each other. We don't need requirements between the programming languages. In fact the hooks can even use different versions of the same programming language. If we have more usecases for this kind of programming, we could definitely pull just a package manager out of pre-commit.

We had something similar before building pre-commit and it served us well for many years. The issue is it grew to be a really long bash file with a lot of copy and pasted code (for lots of different hooks). We built pre-commit to reduce the code duplication and allow all developers to install new hooks that are not installed on the system. We also handle interesting cases like dealing with merge conflicts (see "pre-commit during merges" http://pre-commit.com/#advanced).

aside: It would be cool to support mercurial in the future :D

Hey everyone, creators of pre-commit here. Thought it was a good idea to clarify what makes our project different from most other systems.

Even thought pre-commit is written in python we really don't care about the language that was used to write the hook/linter. If there's a good linter out there written in ruby, you should be able to use it and not have to install ruby/gems/etc. With pre-commit you just say you want scss-lint (https://github.com/causes/scss-lint) in your pre-commit config file and run pre-commit install. When you commit, pre-commit downloads, install scss-lint (without root) and runs the hook against the files you've changed.

Currently we support ruby, node and python and we definitely want to expand the system to support linters in other languages like Go, C/C++ and PHP. We'd really like to support all of these linters - https://github.com/showcases/clean-code-linters.

Ken & Anthony