Re: cherry-pick / pre-commit hook?

[Jakub Narebski <jnareb@gmail.com>]

Junio C Hamano <gitster@pobox.com> writes:

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

Does it mean that for now (and perhaps also for later) it means that
"git commit" by default runs pre-commit hook, unless one use
--no-verify, and that all comands that create a new commit (rebase,
cherry-pick, revert, merge/pull) can request for pre-commit hook to be
run (if they create commit) with --verify?

I think it is a very good idea, though I don't know how difficult it
would be to make all commands that can create commit accept --verify..

-- 
Jakub Narebski
Poland
ShadeHawk on #git