# Re: cloning/pulling hooks 17 messages from 2007-08-29 to 2007-08-29. Participants: Andy Parkins, Petr Baudis, Benjamin Collins, Johannes Schindelin, Junio C Hamano, Alex Riesen. Thread: https://gitlist.dev/t/9685 ## Andy Parkins, 2007-08-29 09:05 Subject: Re: cloning/pulling hooks Message-ID: <200708291005.08795.andyparkins@gmail.com> URL: https://gitlist.dev/e/200708291005.08795.andyparkins%40gmail.com In-Reply-To: <20070828172709.GB1219@pasky.or.cz> ``` 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. Andy -- Dr Andy Parkins, M Eng (hons), MIET andyparkins@gmail.com ``` ## Petr Baudis, 2007-08-29 09:52 Subject: Re: cloning/pulling hooks Message-ID: <20070829095202.GE1219@pasky.or.cz> URL: https://gitlist.dev/e/20070829095202.GE1219%40pasky.or.cz In-Reply-To: <200708291005.08795.andyparkins@gmail.com> ``` On Wed, Aug 29, 2007 at 11:05:07AM CEST, Andy Parkins wrote: > 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. Yes, that was one of my ideas as well; but one thing is that you may want different hooks scripts for different branches or even different times in a particular branch. So maybe .git-hooks/, with each change printing a bit fat warning and setting -x. On the other hand maybe it might be simpler to do the tests for which branch/commit are you working on in the hooks themselves. 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 Early to rise and early to bed makes a male healthy and wealthy and dead. -- James Thurber ``` ## Andy Parkins, 2007-08-29 12:56 Subject: Re: cloning/pulling hooks Message-ID: <200708291356.33126.andyparkins@gmail.com> URL: https://gitlist.dev/e/200708291356.33126.andyparkins%40gmail.com In-Reply-To: <20070829095202.GE1219@pasky.or.cz> ``` 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. Andy -- Dr Andy Parkins, M Eng (hons), MIET andyparkins@gmail.com ``` ## Benjamin Collins, 2007-08-29 13:18 Subject: Re: cloning/pulling hooks Message-ID: URL: https://gitlist.dev/e/b3889dff0708290618s79cffdb5nb6cc69d14efa8b9%40mail.gmail.com In-Reply-To: <20070829095202.GE1219@pasky.or.cz> ``` On 8/29/07, 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? > > -- > 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. -- Benjamin A. Collins http://bloggoergosum.us ``` ## Johannes Schindelin, 2007-08-29 13:21 Subject: Re: cloning/pulling hooks Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0708291421060.28586%40racer.site In-Reply-To: <200708291356.33126.andyparkins@gmail.com> ``` Hi, On Wed, 29 Aug 2007, Andy Parkins wrote: > 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. For me it is 4) put the check into the Makefile where it belongs. Ciao, Dscho ``` ## Petr Baudis, 2007-08-29 13:39 Subject: Re: cloning/pulling hooks Message-ID: <20070829133900.GH1219@pasky.or.cz> URL: https://gitlist.dev/e/20070829133900.GH1219%40pasky.or.cz In-Reply-To: ``` On Wed, Aug 29, 2007 at 03:18:47PM CEST, Benjamin Collins wrote: > On 8/29/07, 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? > > > > -- > > 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. Unfortunately, you didn't really describe a use-case, you just said that you would like them - not what you would use them to. The thing is, so far almost all the use cases would be better off with either using the hooks only at the central repository hub and keeping the developers' freedom locally, or would work better simply somewhere else than in hook files. I'm not saying that this must be the case every time, that is why I'm asking for more input data. -- Petr "Pasky" Baudis Early to rise and early to bed makes a male healthy and wealthy and dead. -- James Thurber ``` ## Johannes Schindelin, 2007-08-29 13:49 Subject: Re: cloning/pulling hooks Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0708291446011.28586%40racer.site In-Reply-To: ``` Hi, 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. Ciao, Dscho ``` ## Petr Baudis, 2007-08-29 13:54 Subject: Re: cloning/pulling hooks Message-ID: <20070829135441.GI10749@pasky.or.cz> URL: https://gitlist.dev/e/20070829135441.GI10749%40pasky.or.cz In-Reply-To: ``` Hi, 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". -- Petr "Pasky" Baudis Early to rise and early to bed makes a male healthy and wealthy and dead. -- James Thurber ``` ## Johannes Schindelin, 2007-08-29 14:06 Subject: Re: cloning/pulling hooks Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0708291502340.28586%40racer.site In-Reply-To: <20070829135441.GI10749@pasky.or.cz> ``` Hi, On Wed, 29 Aug 2007, Petr Baudis wrote: > 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". I think that they are way more than just technical issues: the chicken-and-egg problem is certainly _not_ a technical issue. Besides, another very valid issue is that of portability. Hooks can be _any_ executables. Not just scripts. Not just _bash_ scripts. 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. Ciao, Dscho ``` ## Petr Baudis, 2007-08-29 14:19 Subject: Re: cloning/pulling hooks Message-ID: <20070829141948.GJ10749@pasky.or.cz> URL: https://gitlist.dev/e/20070829141948.GJ10749%40pasky.or.cz In-Reply-To: ``` 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. > Besides, another very valid issue is that of portability. Hooks can be > _any_ executables. Not just scripts. Not just _bash_ scripts. So? That's really up to whoever maintains the repository to sort out. > 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. 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. -- Petr "Pasky" Baudis Early to rise and early to bed makes a male healthy and wealthy and dead. -- James Thurber ``` ## Andy Parkins, 2007-08-29 14:28 Subject: Re: cloning/pulling hooks Message-ID: <200708291528.31599.andyparkins@gmail.com> URL: https://gitlist.dev/e/200708291528.31599.andyparkins%40gmail.com In-Reply-To: ``` On Wednesday 2007 August 29, Johannes Schindelin wrote: > > 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. I suppose you are right, the reason I pick the hook is because I don't mind having untidy code in the working tree but don't want it in the repository. Also, it was given as an example hook so I enabled it :-) Andy -- Dr Andy Parkins, M Eng (hons), MIET andyparkins@gmail.com ``` ## Johannes Schindelin, 2007-08-29 14:31 Subject: Re: cloning/pulling hooks Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0708291529010.28586%40racer.site In-Reply-To: <20070829141948.GJ10749@pasky.or.cz> ``` Hi, 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. Ciao, Dscho ``` ## Petr Baudis, 2007-08-29 14:41 Subject: Re: cloning/pulling hooks Message-ID: <20070829144135.GI1219@pasky.or.cz> URL: https://gitlist.dev/e/20070829144135.GI1219%40pasky.or.cz In-Reply-To: ``` Hi! On Wed, Aug 29, 2007 at 04:31:29PM CEST, Johannes Schindelin wrote: > 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. The hook may depend on some other data checked out as well etc., so I think the simple sane solution is to use the new update hook only for the next update; this should match users' expectations as well. But we got into discussing the details before the fundamentals. :-) > > > _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. How exactly does the Makefile affect what does and what does not get checked in? -- Petr "Pasky" Baudis Early to rise and early to bed makes a male healthy and wealthy and dead. -- James Thurber ``` ## Johannes Schindelin, 2007-08-29 14:56 Subject: Re: cloning/pulling hooks Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0708291555450.28586%40racer.site In-Reply-To: <20070829144135.GI1219@pasky.or.cz> ``` Hi, On Wed, 29 Aug 2007, Petr Baudis wrote: > 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? By refusing to compile when something's not right? Ciao, Dscho ``` ## Junio C Hamano, 2007-08-29 19:45 Subject: Re: cloning/pulling hooks Message-ID: <7vlkbup1kh.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vlkbup1kh.fsf%40gitster.siamese.dyndns.org In-Reply-To: ``` "Benjamin Collins" writes: > On 8/29/07, 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? >> >> -- >> 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. ``` ## Alex Riesen, 2007-08-29 20:27 Subject: Re: cloning/pulling hooks Message-ID: <20070829202726.GC11824@steel.home> URL: https://gitlist.dev/e/20070829202726.GC11824%40steel.home In-Reply-To: <200708291356.33126.andyparkins@gmail.com> ``` Andy Parkins, Wed, Aug 29, 2007 14:56:32 +0200: > 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. It is just a case for "git clone --clone-templates" (which does not exist yet), not for a clone hook. Sometimes, I miss the cloning of .git/description, it probably should be something like: "git clone --clone=templates,config,description". Where config could include a predefined set of harmless config options (like colors or i18n). ``` ## Alex Riesen, 2007-08-29 20:35 Subject: Re: cloning/pulling hooks Message-ID: <20070829203543.GD11824@steel.home> URL: https://gitlist.dev/e/20070829203543.GD11824%40steel.home In-Reply-To: ``` Johannes Schindelin, Wed, Aug 29, 2007 16:56:32 +0200: > > > > 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? > How do I "compile" that pile of .docs which they called "project documentation"? I really do feel for people working for corporate projects: the rules are strict (and often stupid) and there are mistakes and punishment for them. You really don't want to make a merge of a branch containing commits where description is in wrong format (or wrong content, because the customer may see it, and one of the greate rules of bussiness seem to be "hide and obscure"). People prefer to avoid mistakes from happening, then having to correct them (and yes, they do and will commit without doing sanity check). So I think Pasky has a valid point ```