Re: cloning/pulling hooks

"Benjamin Collins" [off-list ref] writes:

On 8/29/07, Petr Baudis [off-list ref] wrote:

quoted

But overally, I'm still not convinced that there is a feasible use-case
for the cloned hooks at all. Someone has a particular example?

--
                                Petr "Pasky" Baudis

My group at work would like this capability.  We have a homogeneous
environment with well-known NFS shares, and some scripts that do
things in this common environment (e.g., release scripts).  It would
be nice if when we do a clone, all the hook scripts (that would be
valid on any machine, in any directory, for any user) would come with
it.

Of course, I understand why it's not already like that, particularly
given the context of Linux development practices.  Still - there are
those of us that think this would be a great convenience.  Having an
option to git-clone to retrieve the parent's hook scripts would be
preferable, and have git-clone just disable them by default.
'git-clone -t repo' or some such.

I do think this is project specific, as such:

 - you can have .git/hooks be a symlink to ../git-hooks/
   (i.e. the project toplevel "git-hooks" directory, or
   whereever the project finds convenient);

 - have "git-hooks" tracked

The latter will take care of the distribution issue.  Now, we
would need a generic and convenient way to make sure that the
new repository "clone" makes has .git/hooks as a symlink to
whereever in-tree that follows the project convention.  I think
you could use the existing templates mechanism.  Allow "git
clone" to take 'template=' parameter and pass it down to "git
init" it invokes.  You use project specific template that
arranges the .git/hooks/ symlink when you clone.  We could even
support "[clone] template = this/template/file" variable in your
$HOME/.gitconfig if we go this route.