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