Re: [PATCH] update-hook: remove all functionality that should be in hooks/post-receive

[Andy Parkins <andyparkins@gmail.com>]

On Saturday 2007, March 24, Junio C Hamano wrote:

> But the recent updates to the mail-hook are backward compatible
> only in the sense that as long as the user configures it, the
> new script can mimic old version's behaviour (in other words, it
> was not backward compatible at all).  I think forcing updates to
> the hooks automatically is worse.  I'd rather keep hooks private
> to repository owner's concern.

But the user is still perfectly fine to /copy/ the script into 
individual repositories; but for those who don't care and just 
want "the latest and greatest" from whatever git supplies a link to the 
sample hook seems like a good solution.  I'm certainly not suggesting 
updating the ones in people's repositories automatically; what I'm 
suggesting is this:

ln -s \
  /usr/doc/git/contrib/post-receive-email
  /var/lib/git/project.git/hooks/post-receive

Or perhaps have the template post-receive hook simply contain

 . /usr/doc/git/contrib/post-receive-email

With the above in place when a user upgrades git with their package 
manager, and they have enabled the default hook script (which simply 
calls the one stored in a known location), they get the upgrade without 
having to think.

> While I think it would be great to have a central clearinghouse
> for people to share and enjoy useful hook collections for
> various workflows and use cases, I do not necessarily think

I agree - filling the place with every hook script that turns up is 
obviously not sensible.  However, this is not a hook collection; nor 
are their "people", there is just me.  Shawn asked if I'd convert the 
existing update hook to post-receive, that's what I did.  Show me these 
other "hook collections" that are desparately trying to get this 
apparently coveted position...

> inside git.git project itself is the best place to do so.

Erm, where is the right place then?

I think that git should supply in git.git a default set that do 
typically wanted things (things like the perfect patch pre-commit hook, 
the no-unannotated-tags update hook, and of course the email sending 
hook) that can be enabled with a simple chmod a+x hooks/somescript.  
All I was doing was supplying a script to fill the post-receive slot.

That all sounds a lot more toys-out-of-pram than I intend; in the end, 
I'm only trying to fix the bugs that are in old update-hook.



Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com