Add support for pre-commit hooks that have file changing side-effects

[Glenn Rempe]

See the discussion in my unworkable pull-request for more details on the motivation for this request.

#235

Overcommit should allow pre-commit hooks to modify, add, or remove files in the working dir prior to a commit. Currently this is not possible and any changes made within the hook code will be silently wiped.

Native git hooks of course can do this so this is in some way a reduction in capability from native hooks.

For example, if a pre-commit hook wanted to automatically update a file with a version number or timestamp in it, this would not be possible since the modification to the file, even if added to the git index during the hook execution, would be removed with a git reset --hard after the pre-commit hooks finish running.

[Shane da Silva]

The more I think about what's involved here the more I'm lead to the conclusion that Overcommit's use of the stack to save/restore changes needs to be replaced by an entirely self-managed system. Not only do we have a lot of logic for dealing with edge cases when dealing with the stash, but it also makes any sort of solution for this feature request to be more difficult since we're ultimately going to need to save changes in a separate store anyway.

Moving towards a model where the working tree is saved/restored manually will take a decent amount of work, but it seems like the right thing to do. I don't have a plan of attack just yet, but wanted to call out that this is certainly something we'd like to solve.

[Glenn Rempe]

Glad to see you are interested in supporting this and doing it the right way. I'll look forward to giving overcommit a more thorough try later.

[Rob Orr]

Is there any estimate of when this enhancement might be complete? We would really like to use overcommit on our repositories, but we need to be able to run autoformatters, such as prettier and autopep8, on our code, and that obviously requires files to be changed. Alternatively, is there a work-around for this issue?

[Shane da Silva]

@rob-orr To my knowledge no one is currently working on this. Would happily welcome someone willing to tackle this and submit a pull request!

[Tomek]

FYI: there is a hacky workaround for this problem

you need to run your custom script in which you will override git stash made by overcommit

for instance

  bundle exec rubocop -a $FILES # auto-correct and change files
  git stash pop . 
  git add .
  git stash save --keep-index

There is one drawback of this workaround, I would not consider it as safe operation as if something goes wrong with stash you may lose your untracked files.

You could be a bit more sure by running apply first and remove stash only after creating new one

  bundle exec rubocop -a $FILES # auto-correct and change files
  git stash apply
  git add .
  git stash save --keep-index
  git stash drop stash@{1}

[Senya]

It seems that lint-staged written in JS handles this issue properly: https://github.com/okonet/lint-staged

I wonder how different is overcommit and why is it they handle it in lint-staged while overcommit cannot. Is there any concept or idea we could copy from lint-staged?

[Michał Matyas]

Are there any plans to revisit this issue?

[Shane da Silva]

Open to a pull request!