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, 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 -- 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