Re: cherry-pick / pre-commit hook?

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 28, 2010, 18:16 UTC
Message-ID: <7vy679wynd.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20101227093729.GB1201@burratino>

Jonathan Nieder <jrnieder@gmail.com> writes:

Show 16 quoted lines

> 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).