Show HN: Pre-commit – A framework for managing multi-language pre-commit hooks • Hacker News Board

Re: Show HN: Pre-commit – A framework for managing multi-language pre-commit hooks

#11

Post by icefox » Wed, Aug 27, 2014, 7:23 PM UTC

struys wrote: post #9

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 wan…

So pre-commit is just a package manager in disguise?

To the extreme you could have a demo package where to build the demo you actually have to run git commit -m "world" and the pre-commit would install gcc and all of the dependencies and then run a build, letting the commit success if the build passes. ;D

Re: Show HN: Pre-commit – A framework for managing multi-language pre-commit hooks

#12

Post by struys » Wed, Aug 27, 2014, 11:31 PM UTC

icefox wrote: post #11

struys wrote: post #9

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 wan…

So pre-commit is just a package manager in disguise? To the extreme you could have a demo package where to build the demo you actually have to run git commit -m "world" and the pre-commit would install gcc and all of the dependencies and then run a build, letting the commit success if the build passes. ;D

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.

Re: Show HN: Pre-commit – A framework for managing multi-language pre-commit hooks

#13

Post by contingencies » Thu, Aug 28, 2014, 2:04 AM UTC

struys wrote: post #9

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 wan…

Good job guys - I do think there's space for a broadly applicable solution in this space. The main selling points for a solution in this area, for us, are:

(1) a strong remote registry implementation (available hooks, preferably auto-matched to auto-detected languages present, perhaps using file/libmagic and language syntax versioning); and

(2) the ability to spec default behavior remotely in a company-wide registry, but then to override at two levels: that of checked in files within the repo, and .gitignore'd local developer-specific prefs.

I'm definitely going to look at this further. To speed adoption, I'd encourage you to avoid assumptions around people's de-facto desire for all but the most basic levels of linting (iffy warnings, etc.), ie. make sure the defaults are very light touch ... but useful. Convenience is key.

However, please don't encourage curl-based installs!

Re: Show HN: Pre-commit – A framework for managing multi-language pre-commit hooks

#14

Post by michaelmior » Thu, Aug 28, 2014, 2:15 AM UTC

icefox wrote: post #7

Another shameless plug, for my git-hooks project I wrote a few years ago https://github.com/icefox/git-hooks It is a single small bash script with no external depenandancies so it just needs to be in your path. git-hooks provide a way to manage and share your hooks using three+ locations: User hooks, installed in ~/.git_hooks/ Project hooks, installed in .git/git_hooks/ in a project. Global hooks, specified with the…

Thanks for this! It's been a while, but I did use it a year or so ago for a project at work and it was quite handy. It's unfortunate that git doesn't have something like this built-in.

Re: Show HN: Pre-commit – A framework for managing multi-language pre-commit hooks

#15

Post by struys » Thu, Aug 28, 2014, 4:22 AM UTC

contingencies wrote: post #13

struys wrote: post #9

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 wan…

Good job guys - I do think there's space for a broadly applicable solution in this space. The main selling points for a solution in this area, for us, are: (1) a strong remote registry implementation (available hooks, preferably auto-matched to auto-detected languages present, perhaps using file / libmagic and language syntax versioning); and (2) the ability to spec default behavior remotely in a company-wide registr…

(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 ` and `pre-commit add `.

(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.