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

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

[Ray Xie]

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.

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

[David Aguilar]

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

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

[Ray Xie]

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

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

[Stefan Beller]

> so it's a sever side hook that it's forced down to all developers.

How does that work?

/me is just curious