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:

> You know what?  I am very tempted to take this patch, while
> dropping the other one.  Well, dropping is probably not quite
> accurate, because being a nice person (and I am good looking,
> too ;-), I would probably end up creating "contrib/mailhook/"
> hierarchy and stash the contents of your second patch there
> myself.

I'm inclined to agree.  This one is obviously good because the hook 
script gets simpler.

> I think I'd better let fancier hooks live in contrib/examples
> hierarchy for people to pick and choose, and keep the default
> templates/ directory lean and clean.

I really wasn't trying to be fancy; just complete.  I hope that with 
this script that every possible type of reference update is caught and 
reported correctly.  Unfortunately that makes the script large and 
uncomfortable to put in a template directory; particularly as it's only 
really useful in a bare repository so every user wouldn't want to have 
it.  (incidentally, I've long thought that there should be two template 
directories - one for bare and one for working)

> The thing is, not many people are interested in sending e-mail
> out from post- any hooks (I don't do so, Linus doesn't either),

I'm not sure that two people is a representative sample for the "not 
many people are interested" case.  The times I think people will use it 
commonly is for internal projects.  I have this script activated on 
every project I work on, but not one of them is open source.  They all 
report to the interested parties so they know when to update their own 
repositories (or for a manager to see when a release is made).

Having said all that; I don't like the idea of putting this in the 
standard git templates; but not (primarily) for the reason of size.  
The problem, I think, is that of bug fixes.  At the moment, I copy the 
script from the templates directory to a projects/git/ directory, then 
for each repository within that I symbolic link the 
projects/git/project.git/hooks/post-receive file to the master script. 
This is still not a good solution because I have to manually copy the 
script if I ever upgrade git (or more likely a package manager upgrades 
it), so any bug fixes in the hook script don't get automatically 
implemented.

So: ideally, what /I/ would like is that git distributes the script in a 
standard location like /usr/share/doc/git/contrib/post-receive-emailer 
with the execute bit already set; that can be easily linked to or 
called from the actual post-receive hook.



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