Re: cloning/pulling hooks

> On Tue, Aug 28, 2007 at 06:46:48PM CEST, Josh England wrote:
> > When cloning an existing repository, is there any way to grab
> > the .git/hooks files as part of the clone (or pull)?
>
>   No. You can add the appropriate instructions to instructions how to
> clone the repository, users have to install the hooks manually.
>
>   Now I went on with a large writeup on considerations for implementing
> such a feature (including security), but then I scrapped it. What would
> you like to use these hooks for? Really, perhaps it's best to instead do
> any "post-commit" etc. checks at the push time instead of the commit
> time, so that developers can still freely commit locally, e.g. I
> sometimes do temporary commits on side branches of various work in
> progress changes, then randomly merge them together etc. before I come
> up with the final sequence of commits that I push out.

> On Tuesday 2007 August 28, Petr Baudis wrote:
> 
> > On Tue, Aug 28, 2007 at 06:46:48PM CEST, Josh England wrote:
> > > When cloning an existing repository, is there any way to grab
> > > the .git/hooks files as part of the clone (or pull)?
> >
> >   No. You can add the appropriate instructions to instructions how to
> > clone the repository, users have to install the hooks manually.
> >
> >   Now I went on with a large writeup on considerations for implementing
> > such a feature (including security), but then I scrapped it. What would
> > you like to use these hooks for? Really, perhaps it's best to instead do
> > any "post-commit" etc. checks at the push time instead of the commit
> > time, so that developers can still freely commit locally, e.g. I
> > sometimes do temporary commits on side branches of various work in
> > progress changes, then randomly merge them together etc. before I come
> > up with the final sequence of commits that I push out.
> 
> I've not done it for myself yet, but I had an idea about making an independent 
> branch in the repository itself containing the hook scripts for that project.  
> That way, the cloners get the scripts but still have to knowingly install 
> them themselves.
> 
> If you were feeling particularly brave, you could check that branch out 
> in .git/hooks.

> On Wednesday 2007 August 29, Petr Baudis 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?
> 
> Hits me all the time.
> 
> 1) Start a new project
> 2) Install a pre-commit hook that checks that every patch meets some
>    arbitrary coding standard
> 3) Clone to laptop
> 4) Kick self the first time you make a commit that doesn't adhere to coding
>    standards that would have been enforced by the hook script.

> > 1) Start a new project
> > 2) Install a pre-commit hook that checks that every patch meets some
> >    arbitrary coding standard
> > 3) Clone to laptop
> > 4) Kick self the first time you make a commit that doesn't adhere to
> > coding standards that would have been enforced by the hook script.
>
> For me it is
>
> 4) put the check into the Makefile where it belongs.

> On Wednesday 2007 August 29, Petr Baudis 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?
> 
> Hits me all the time.
> 
> 1) Start a new project
> 2) Install a pre-commit hook that checks that every patch meets some
>    arbitrary coding standard
> 3) Clone to laptop
> 4) Kick self the first time you make a commit that doesn't adhere to coding
>    standards that would have been enforced by the hook script.
> 
> The problem is that my brain thinks that cloning gets me the same 
> configuration as the source, but obviously it doesn't and I forget that I 
> need to clone _then_ scp .git/config and .git/hooks/*.
> 
> I understand that these things are a security risk to do automatically, and I 
> don't think I'd advocate that.  However, it would be useful to be able to 
> grab those files as well.

> 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

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

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

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

> The other issue I raised, however, seemed to die away in the other noise:
> 
> _Why_ on earth do you want to put something into the SCM specific 
> meta-data which should be part of the build process _to begin with_?
> 
> _All_ of the arguments I read are along the lines "we want to enforce some 
> coding styles" or similar.  These issues are _orthogonal_ to the question 
> which SCM is used.

> On Wed, Aug 29, 2007 at 04:06:17PM CEST, Johannes Schindelin wrote:
> > I think that they are way more than just technical issues: the 
> > chicken-and-egg problem is certainly _not_ a technical issue.
> 
> What do you mean by the chicken-and-egg problem? I think I missed that.

> > _All_ of the arguments I read are along the lines "we want to enforce 
> > some coding styles" or similar.  These issues are _orthogonal_ to the 
> > question which SCM is used.
> 
> Your company has certain rules on how all the source on the public 
> branches should look like, etc. It's not quite clear to me how can build 
> system enforce these rules.

> On Wed, 29 Aug 2007, Petr Baudis wrote:
> 
> > On Wed, Aug 29, 2007 at 04:06:17PM CEST, Johannes Schindelin wrote:
> > > I think that they are way more than just technical issues: the 
> > > chicken-and-egg problem is certainly _not_ a technical issue.
> > 
> > What do you mean by the chicken-and-egg problem? I think I missed that.
> 
> What if hooks/update is in your set?  It _does not_ run before it is 
> checked out, but of course, some ref is updated before it is checked out.

> > > _All_ of the arguments I read are along the lines "we want to enforce 
> > > some coding styles" or similar.  These issues are _orthogonal_ to the 
> > > question which SCM is used.
> > 
> > Your company has certain rules on how all the source on the public 
> > branches should look like, etc. It's not quite clear to me how can build 
> > system enforce these rules.
> 
> The same as a hook.  You just put the check into the Makefile.

> On Wed, Aug 29, 2007 at 04:31:29PM CEST, Johannes Schindelin wrote:
>
> > Pasky wrote:
> >
> > > Your company has certain rules on how all the source on the public 
> > > branches should look like, etc. It's not quite clear to me how can 
> > > build system enforce these rules.
> > 
> > The same as a hook.  You just put the check into the Makefile.
> 
> How exactly does the Makefile affect what does and what does not get 
> checked in?

> > > > Your company has certain rules on how all the source on the public 
> > > > branches should look like, etc. It's not quite clear to me how can 
> > > > build system enforce these rules.
> > > 
> > > The same as a hook.  You just put the check into the Makefile.
> > 
> > How exactly does the Makefile affect what does and what does not get 
> > checked in?
> 
> By refusing to compile when something's not right?
> 

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