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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]