Skip Git commit hooks

With both comment and no verify without any further issue:

git commit -m "Some comments" --no-verify

From man githooks:

pre-commit
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.

Maybe (from git commit man page):

git commit --no-verify -m "commit message"
           ^^^^^^^^^^^
-n  
--no-verify

This option bypasses the pre-commit and commit-msg hooks. See also githooks(5).

As commented by Blaise, -n can have a different role for certain commands.
For instance, git push -n is actually a dry-run push.
Only git push --no-verify would skip the hook.

---

Note: Git 2.14.x/2.15 improves the --no-verify behavior:

See commit 680ee55 (14 Aug 2017) by Kevin Willford (``).
^{(Merged by Junio C Hamano -- gitster -- in commit c3e034f, 23 Aug 2017)}

commit: skip discarding the index if there is no pre-commit hook

"git commit" used to discard the index and re-read from the filesystem just in case the pre-commit hook has updated it in the middle; this has been optimized out when we know we do not run the pre-commit hook.

---

Davi Lima points out in the comments the git cherry-pick does not support --no-verify.
So if a cherry-pick triggers a pre-commit hook, you might, as in this blog post, have to comment/disable somehow that hook in order for your git cherry-pick to proceed.

The same process would be necessary in case of a git rebase --continue, after a merge conflict resolution.

---

With Git 2.36 (Q2 2022), the callers of run_commit_hook() to learn if it got "success" because the hook succeeded or because there wasn't any hook.

See commit a8cc594 (fixed with commit 4369e3a1), commit 9f6e63b (07 Mar 2022) by Ævar Arnfjörð Bjarmason (avar).
^{(Merged by Junio C Hamano -- gitster -- in commit 7431379, 16 Mar 2022)}

hooks: fix an obscure TOCTOU "did we just run a hook?" race

^{Signed-off-by: Ævar Arnfjörð Bjarmason}

Fix a Time-of-check to time-of-use (TOCTOU) race in code added in 680ee55 ("commit: skip discarding the index if there is no pre-commit hook", 2017-08-14, Git v2.15.0-rc0 -- merge listed in batch #3).

This obscure race condition can occur if we e.g. ran the "pre-commit" hook and it modified the index, but hook_exists() returns false later on (e.g., because the hook itself went away, the directory became unreadable, etc.).
Then we won't call discard_cache() when we should have.

The race condition itself probably doesn't matter, and users would have been unlikely to run into it in practice.
This problem has been noted on-list when 680ee55 was discussed, but had not been fixed.

Let's also change this for the push-to-checkout hook.
Now instead of checking if the hook exists and either doing a push to checkout or a push to deploy we'll always attempt a push to checkout.
If the hook doesn't exist we'll fall back on push to deploy.
The same behavior as before, without the TOCTOU race.
See 0855331 ("receive-pack: support push-to-checkout hook", 2014-12-01, Git v2.4.0-rc0 -- merge) for the introduction of the previous behavior.

This leaves uses of hook_exists() in two places that matter.
The "reference-transaction" check in refs.c, see 6754159 ("refs: implement reference transaction hook", 2020-06-19, Git v2.28.0-rc0 -- merge listed in batch #7), and the "prepare-commit-msg" hook, see 66618a5 ("sequencer: run 'prepare-commit-msg' hook", 2018-01-24, Git v2.17.0-rc0 -- merge listed in batch #2).

In both of those cases we're saving ourselves CPU time by not preparing data for the hook that we'll then do nothing with if we don't have the hook.
So using this "invoked_hook" pattern doesn't make sense in those cases.

The "reference-transaction" and "prepare-commit-msg" hook also aren't racy.
In those cases we'll skip the hook runs if we race with a new hook being added, whereas in the TOCTOU races being fixed here we were incorrectly skipping the required post-hook logic.