Re: cherry-pick / pre-commit hook?

From: Jakub Narebski <jnareb@gmail.com>
Date: Dec 28, 2010, 22:38 UTC
Message-ID: <m3vd2djzhp.fsf@localhost.localdomain>
In-Reply-To: <7vy679wynd.fsf@alter.siamese.dyndns.org>

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

Show 18 quoted lines

> 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