Re: cloning/pulling hooks

> On Wed, Aug 29, 2007 at 03:49:45PM CEST, Johannes Schindelin wrote:
> > On Wed, 29 Aug 2007, Benjamin Collins wrote:
> > 
> > > Of course, I understand why it's not already like that, particularly 
> > > given the context of Linux development practices.
> > 
> > It has nothing to do with Linux development practices.  There are 
> > fundamental reasons why we don't fetch hooks:
> > 
> > - they are _not_ part of the repository; just look at the 
> >   .gitattributes-in-the-index-but-not-worktree issue to find out why,
> > 
> > - it is _private_ data, just like the config.  The client has _no 
> >   business_ to read them, let alone fetch them,
> > 
> > - if you have the hooks on different machines, chances are that you need a 
> >   mechanism to update the hooks... This naturally suggests putting the 
> >   hooks into their own branch.
> > 
> > Probably there are way more reasons not to allow such a thing as fetching 
> > hooks.
> 
>   these are all really just technical details - if we decided that it
> _is_ useful to have a mechanism to manage hooks, it really is no problem
> to introduce some easy-to-use automated way to keep .git/hooks/ updated
> based on some head, have .git-hooks/ as part of your current branch, or
> whatever. And of course, "fetching hooks" may not (and very frequently
> you wouldn't ever want it to) mean "grabbing the same hooks the server
> uses".