Re: cherry-pick / pre-commit hook?

[Dave Abrahams <dave@boostpro.com>]

At Tue, 28 Dec 2010 14:38:20 -0800 (PST),
Jakub Narebski wrote:
> 
> 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

+1!

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com