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").

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

Reply via email to