Hi Jonathan, At Wed, 8 Dec 2010 11:53:24 -0600, Jonathan Nieder wrote: > > $ git show -s 9fa4db5 > commit 9fa4db544e2e4d6c931f6adabc5270daec041536 > Author: Junio C Hamano <junkio@xxxxxxx> > Date: Mon Aug 29 21:19:04 2005 -0700 > > Do not verify reverted/cherry-picked/rebased patches. > > The original committer may have used validation criteria that is less > stricter than yours. You do not want to lose the changes even if they > are done in substandard way from your 'commit -v' verifier's point of > view. > > Signed-off-by: Junio C Hamano <junkio@xxxxxxx> > $ > > At last, an answer. The main purpose of the pre-commit hook (and > builtin checks that preceded it) is to avoid introducing regressions > in whitespace style, encoding, and so forth; but it would make > cherry-picking unnecessarily difficult, without preventing > regressions, to apply the same standards to existing code. I suspected as much. > > > Is there a hook that cherry-pick > > /will/ run instead? > > "git log --grep=pre-commit" seems to suggest that the commit-msg and > post-commit hooks will be run. But first, what are you trying to > accomplish? You're going to love this: I had sent a pull request upstream and the maintainer of the project rejected my changes because I didn't follow some formatting convention he didn't tell me about ;-). So I set up a commit hook that would prevent me from making the same mistake again, and cherry-picked the changes one-by-one. So it was exactly the same scenario, except I am the author of the original changes. I wonder whether this would have gone better had I used rebase. > Maybe there is a simpler way, or maybe with that use > case in mind we can make changes to support it better. Looking forward to hearing more. Thanks, -- 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