Junio C Hamano wrote: > We already encourage casting-in-stone a particular version of the > sample hook when a new repository is created by copying them from > the template directory. This prevents from surprising users when an > updated version of Git changes the behaviour of these samples. Even > if you think bugs in older ones may be corrected in newer ones, > silently updating the hook the user chose to use by inspecting one > particular version is not something we would want to do lightly. For context, the sample hooks you are talking about are the *.sample files from the templates/ directory. Except for post-update.sample, most are not very useful out of the box, and they are very much intended as examples to start people's thinking, as opposed to something one-size-fits-all. By contrast, the post-receive-email script from contrib is a complete program with a well-defined behavior and configuration that have stayed consistent while the details of its implementation improved. It can be used by symlinking into place, but maybe a better set of instructions would say # This script takes no arguments and expects the same input format # as git's post-receive hook, so if this script is at # /usr/share/git-core/contrib/hooks/post-receive-email (as it is # on Debian and Fedora), you can do # # cd /path/to/your/repository.git # echo '#!/bin/sh' >hooks/post-receive # echo 'exec /usr/share/git-core/contrib/hooks/post-receive-email' \ # >>hooks/post-receive # chmod +x hooks/post-receive That would make it more obvious what I can do next if my post-receive input should be passed both to post-receive-email and some other tool (perhaps in a pipeline using "tee"). Hmm? Jonathan -- 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