Re: cloning/pulling hooks

[Junio C Hamano <gitster@pobox.com>]

"Benjamin Collins" <aggieben@gmail.com> writes:

> On 8/29/07, Petr Baudis <pasky@suse.cz> wrote:
>> 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.