Andy Parkins [off-list ref] writes:
Now that we have a post-receive hook; the update hook's only job is to
decide is a particular update is allowed or not.
This example hook removes all of the functionality that should now
rightly be done by the post-receive hook. In particular: the generation
of notification emails.
Signed-off-by: Andy Parkins <redacted>
I was quite impressed by seeing what Shawn did with his
'continuous' stuff, not the way it is implemented, but the way
it was presented as "you can do this to use it from your hook
script".
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 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.
There is a small detail of how users who use prepackaged git
would get rich library of example hooks from, but that is
something better left to distro people; that way I do not have
to worry about them too much, and it would also make it crystal
clear that these are just examples.
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),
and there is no strong justifiation to give e-mail sending users
any preferential treatment and penalize others by copying rather
huge hook scripts from templates/ that they are not going to
ever use.
On Fri, 23 Mar 2007, Junio C Hamano wrote:
.. because being a nice person (and I am good looking,
too ;-)
Snif. My boy has all grown up.
There is nothing more I can teach you, grasshopper.
Linus
Junio C Hamano [off-list ref] wrote:
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 agree. Which is why I submitted my little continuous integration
server as contrib/continuous and not as a hook in templates.
;-)
--
Shawn.
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
On Sat, Mar 24, 2007 at 08:14:31AM +0000, Andy Parkins wrote:
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.
I wonder if this is a good idea to do for all or most of the template
scripts, so that they can get automatically updated when git is
updated, instead of having the problem we had before where the hook
script got updated to match changes in git, but ancient repositories
would still have the old script.
- Ted