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

David,

Thanks for the suggestions, I left out the most unfortunate part of the problem I am facing, the one that add this hook is the git admin, aka our release engineer, so it's a sever side hook that it's forced down to all developers. I sure will try to persuade them from a different perspective more calmly this time.

Regards,
Ray

quoted

On Mar 20, 2015, at 12:16 AM, David Aguilar [off-list ref] 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