Jonathan Nieder <jrnieder@xxxxxxxxx> writes:
> Dave Abrahams wrote:
>
>> if you're going to have a "pre-commit hook" concept,
>> but not run that hook for some kinds of commits, then that fact needs
>> to be documented.
>
> True, and thanks for a reminder. Suggested wording?
>
> The current githooks(5) says
>
> pre-commit
> This hook is invoked by git commit, and can be bypassed with
> --no-verify option.
>
> and leaves the question of whether it is invoked by git cherry-pick
> unanswered.
Yeah, but do we want to answer it in this section, or in git-cherry-pick's
manual page?
After all "pre-commit" was _not_ about "before doing anything that creates
a commit", but was about "before git-commit creates a commit". Changing
that definition is fine as long as we have a good way to explain it to the
users and more importantly a simple rule that the users can understand,
and that rule _could_ be "anything that creates a new commit".
In reality "anything that creates a new commit" cannot be that simple
rule, however. For example, "git pull" does attempt to create a new merge
commit, but failing it because the work done by the other person you are
pulling from does not conform _your_ standard defined by your hook is not
a sane default.
I think the basic direction could be (I haven't thought things through,
just a strawman):
- Allow --verify/--no-verify to all commands that possibly create a new
commit, and run pre-commit hook where an updated index is about to be
made into a commit (for some commands this may not be very easy);
- The guideline of picking the default would probably look like this:
(1) for existing commands, keep the current behaviour;
(2) for a new command, --verify should be the default if the command is
primarily about letting the user do what s/he would/could/should
have done as "git commit" in the first place (e.g. cherry-picking
one's own commit from a separate branch or rebasing one's own
unpublished branch on top of updated upstream), and --no-verify
otherwise (i.e. taking other's work and using it in a context
different from the original).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html