I setup some git hooks to run some gulp
commands on pre-commit. I basically run jshint
/plato
. I basically want to bypass these for two cases:
The plato gulp command runs analysis on the source and produces a /reports/ directory that tracks complexity over time. If we do this on the hotfix branch it will result in merge conflicts when merging them back into development. Enough talking here is the simple hook:
#!/bin/sh if git diff --cached --name-only --diff-filter=ACM | grep '.js$' >/dev/null 2>&1 then git stash -q --keep-index ./node_modules/.bin/gulp jshint RESULT=$? git stash pop -q [ $RESULT -ne 0 ] && exit 1 git stash -q --keep-index ./node_modules/.bin/gulp plato git add report/ git stash pop -q fi exit 0
Issue right now is if i have a merge conflict on "reports" and I resolve the merge All conflicts fixed but you are still merging.
and then commit it runs the analysis again and stages the commit and when it commits it throws an error:
/Users/Nix/work/project/.git/modules/somesubmodule/MERGE_HEAD' for reading: No such file or directory.
The directory does exist but there is no merge head...
Use the --no-verify option to skip git commit hooks, e.g. git commit -m "commit message" --no-verify . When the --no-verify option is used, the pre-commit and commit-msg hooks are bypassed.
#Solution 1:Delete the . git/hook folder and then do the npm install for reinstall husky. There are chances for conflicts with husky-generated files and . git/hook/ files.
This hook is invoked by git commit, and can be bypassed with --no-verify option. It takes no parameter, and is invoked before obtaining the proposed commit log message and making a commit. Exiting with non-zero status from this script causes the git commit to abort.
You can set HUSKY environment variable to 0 in your CI config file, to disable hooks installation. Alternatively, most Continuous Integration Servers set a CI environment variable. You can use it in your hooks to detect if it's running in a CI.
So I just found a command that I think i can use to detect the "merge_head"
git rev-parse -q --verify MERGE_HEAD
If rev-parse returns a hash that means we are currently in a merge state. I can use that to bypass this logic. But will wait for some better advice from more experienced individuals.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With