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 <dav...@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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
