Re: cherry-pick / pre-commit hook?

[Dave Abrahams <dave@boostpro.com>]

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@cox.net>
>  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@cox.net>
>  $
> 
> 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