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