"Benjamin Collins" <aggieben@xxxxxxxxx> writes: > On 8/29/07, Petr Baudis <pasky@xxxxxxx> 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. - 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
