pre-commit hooks has false positives #4
Comments
|
As seen in #2 there could be some serious flaws when you programmatically do a |
|
So, i've been thinking about this. We could implement an option which will stash automatically and have it turned off by default. |
|
I think that the issue with stash as mentioned in #2 is not an issue (at least not anymore). The problem with that mentioned comment is that if you remove a line from a file, git will remove all changes in that file from stage. So the If you run I tested it with Git 2.3.0, so I'm not sure how older versions handle it. |
|
👍 here. |
boneskull
added a commit
to boneskull/pre-commit
that referenced
this issue
Sep 14, 2015
…ng#4 - `precommit.stash` is now configurable in `package.json`; set to `false` to avoid stashing
boneskull
added a commit
to boneskull/pre-commit
that referenced
this issue
Sep 14, 2015
…ng#4 - `precommit.stash` is now configurable in `package.json`; set to `false` to avoid stashing
kevinoid
added a commit
to kevinoid/pre-commit
that referenced
this issue
Feb 6, 2016
In order to ensure any pre-commit tests are run against the files as they will appear in the commit, this commit adds an option to run `git stash` to save any changes to the working tree before running the scripts, then restore any changes after the scripts finish. The save/restore procedure is based on Chris Torek's StackOverflow answer to a question asking how to do exactly this.[1] This implementation does not do a hard reset before restoring the stash by default, since it assumes that if scripts modify tracked files the changes should be kept. But it does provide this behavior, and `git clean`, as configurable options. It follows the convention requested in observing#4 by making the new stash option default to off. Although there are no known implementation issues (with the exception of the git bug noted in Torek's SO answer), current scripts may expect modified/untracked files to exist or modify untracked files in a way which prevents applying the stash, making default-on behavior backwards-incompatible. The tests are split into a separate file. Since each stash option is tested against a project repository and a clean/reset is done between each test, the tests are somewhat slow. This way the tests are not run by default, but are run as test-stash, as part of test-all, and as part of test-travis. This commit is based off of the work of Christopher Hiller in observing#47, although the implementation differs significantly due to the use of Promises in place of async, which I found to be significantly clearer, more flexible, and they make the tests significantly more concise. Fixes: observing#4 1. https://stackoverflow.com/a/20480591 Signed-off-by: Christopher Hiller <[email protected]> [[email protected]: Reimplement using Promises and Torek's method] Signed-off-by: Kevin Locke <[email protected]>
kevinoid
added a commit
to kevinoid/pre-commit
that referenced
this issue
Feb 6, 2016
In order to ensure any pre-commit tests are run against the files as they will appear in the commit, this commit adds an option to run `git stash` to save any changes to the working tree before running the scripts, then restore any changes after the scripts finish. The save/restore procedure is based on Chris Torek's StackOverflow answer to a question asking how to do exactly this.[1] This implementation does not do a hard reset before restoring the stash by default, since it assumes that if scripts modify tracked files the changes should be kept. But it does provide this behavior, and `git clean`, as configurable options. It follows the convention requested in observing#4 by making the new stash option default to off. Although there are no known implementation issues (with the exception of the git bug noted in Torek's SO answer), current scripts may expect modified/untracked files to exist or modify untracked files in a way which prevents applying the stash, making default-on behavior backwards-incompatible. The tests are split into a separate file. Since each stash option is tested against a project repository and a clean/reset is done between each test, the tests are somewhat slow. This way the tests are not run by default, but are run as test-stash, as part of test-all, and as part of test-travis. This commit is based off of the work of Christopher Hiller in observing#47, although the implementation differs significantly due to the use of Promises in place of async, which I found to be significantly clearer, more flexible, and they make the tests significantly more concise. Fixes: observing#4 1. https://stackoverflow.com/a/20480591 Signed-off-by: Christopher Hiller <[email protected]> [[email protected]: Reimplement using Promises and Torek's method] Signed-off-by: Kevin Locke <[email protected]>
kevinoid
added a commit
to kevinoid/pre-commit
that referenced
this issue
Feb 6, 2016
In order to ensure any pre-commit tests are run against the files as they will appear in the commit, this commit adds an option to run `git stash` to save any changes to the working tree before running the scripts, then restore any changes after the scripts finish. The save/restore procedure is based on Chris Torek's StackOverflow answer to a question asking how to do exactly this.[1] This implementation does not do a hard reset before restoring the stash by default, since it assumes that if scripts modify tracked files the changes should be kept. But it does provide this behavior, and `git clean`, as configurable options. It follows the convention requested in observing#4 by making the new stash option default to off. Although there are no known implementation issues (with the exception of the git bug noted in Torek's SO answer), current scripts may expect modified/untracked files to exist or modify untracked files in a way which prevents applying the stash, making default-on behavior backwards-incompatible. The tests are split into a separate file. Since each stash option is tested against a project repository and a clean/reset is done between each test, the tests are somewhat slow. By splitting the tests into a separate file, we can avoid running them by default. They can instead be run as test-stash, as part of test-all, and as part of test-travis. This commit is based off of the work of Christopher Hiller in observing#47, although the implementation differs significantly due to the use of Promises in place of async, which I found to be significantly clearer, more flexible, and they make the tests significantly more concise. Fixes: observing#4 1. https://stackoverflow.com/a/20480591 Signed-off-by: Christopher Hiller <[email protected]> [[email protected]: Reimplement using Promises and Torek's method] Signed-off-by: Kevin Locke <[email protected]>
kevinoid
added a commit
to kevinoid/pre-commit
that referenced
this issue
Feb 6, 2016
In order to ensure any pre-commit tests are run against the files as they will appear in the commit, this commit adds an option to run `git stash` to save any changes to the working tree before running the scripts, then restore any changes after the scripts finish. The save/restore procedure is based on Chris Torek's StackOverflow answer to a question asking how to do exactly this.[1] This implementation does not do a hard reset before restoring the stash by default, since it assumes that if scripts modify tracked files the changes should be kept. But it does provide this behavior, and `git clean`, as configurable options. It follows the convention requested in observing#4 by making the new stash option default to off. Although there are no known implementation issues (with the exception of the git bug noted in Torek's SO answer), current scripts may expect modified/untracked files to exist or modify untracked files in a way which prevents applying the stash, making default-on behavior backwards-incompatible. The tests are split into a separate file. Since each stash option is tested against a project repository and a clean/reset is done between each test, the tests are somewhat slow. By splitting the tests into a separate file, we can avoid running them by default. They can instead be run as test-stash, as part of test-all, and as part of test-travis. This commit is based off of the work of Christopher Hiller in observing#47, although the implementation differs significantly due to the use of Promises in place of async, which I found to be significantly clearer, more flexible, and they make the tests significantly more concise. Fixes: observing#4 1. https://stackoverflow.com/a/20480591 Signed-off-by: Christopher Hiller <[email protected]> [[email protected]: Reimplement using Promises and Torek's method] Signed-off-by: Kevin Locke <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When I use
git add -por evengit add some filesit will run my tests before the commit however the tests pass because of the unstaged changes I have locally.If I were to stash before running
npm testthen the tests would have failed.Is it the responsibility of
pre-committo ensure that the tests pass based on only the staged changes or is that the users responsibility ?The text was updated successfully, but these errors were encountered: