Re: A git hook that does git cherry-pick and push automatically

>> On Mar 20, 2015, at 12:16 AM, David Aguilar <davvid@gmail.com> wrote:
>> 
>> On Thu, Mar 19, 2015 at 09:07:28PM -0700, Ray Xie wrote:
>> So today I had a shocking moment while I was doing my cherry-pick,
>> after I performed all the pre-checkin duties (the usual build the
>> code, run the test to make sure the cherry-pick infact works), I found
>> out that my original commit was already cherry-picked, then I found
>> out someone in engineering make the decision to do an automate
>> cherry-pick from that branch to another so he added a git hook to run
>> do cherry-pick and push on every commit, yes, a simple cherry-pick
>> then push; mind you, these are not feature / dev branch, these are
>> release branches, both of them.
>> 
>> Then after I came back from the shock, made a big protest about how
>> this is the worst thing I have seen and I will never live with it, and
>> that's why "git cherry-pick" and "git push" are 2 separate commands,
>> as any reasonable developer, you do your very best to ensure you are
>> not pushing something that is fundamentally broken; however for the
>> life of me and talk these few people into senses.
>> 
>> So, I am sending this to seek for some expert advice how I can drive
>> some sense into these people so they don't screw up my life as an
>> developer.
>> 
>> Regards,
>> Desperate developer, Ray.
> 
> It's interesting that your clone picked up the hooks that they
> added.  Do you have a centrally managed git installation, where
> perhaps they are modifying the default .git/hooks/ template that
> is used to seed the initial repo when cloning?
> 
> One way to check that is to look at your git installation.
> If your git is installed as /usr/bin/git then check
> /usr/share/git-core/templates and see if the hook is present
> there.
> 
> Assuming that you have the ability to create your own clones,
> and that you are not all working in a common shared sandbox,
> then the simplest solution would be to simply delete your
> .git/hooks/* when cloning a new repo.
> 
> That way you can at least have your sandboxes work the way
> you want them to work.  Hooks are local to your sandbox so you
> have full control over them.
> 
> Is this hook resilient to rebasing?  Does it cause havoc if you
> a feature onto this branch?  Those are the kinds of things that
> sound scary based on your description of the hook.
> 
> I don't have any tips on how to convince people.  One thing that
> might help is to remember that people are self-motivated ~ try
> to focus on what *they* stand to benefit from not having this
> hook.  If you can convince them that they are better-off without
> the hook, from their POV, not from yours, then you might have a
> better chance of persuading them.
> 
> Good luck,
> -- 
> David