{"thread":{"id":"9685","subject":"Re: cloning/pulling hooks","startedAt":"2007-08-29T09:05:07Z","lastAt":"2007-08-29T20:35:43Z","messageCount":17,"participants":["Andy Parkins","Petr Baudis","Benjamin Collins","Johannes Schindelin","Junio C Hamano","Alex Riesen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"51785","messageId":"200708291005.08795.andyparkins@gmail.com","threadId":"9685","inReplyTo":"20070828172709.GB1219@pasky.or.cz","subject":"Re: cloning/pulling hooks","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-08-29T09:05:07Z","receivedAt":"2007-08-29T09:05:07Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Tuesday 2007 August 28, Petr Baudis wrote:\n\n> On Tue, Aug 28, 2007 at 06:46:48PM CEST, Josh England wrote:\n> > When cloning an existing repository, is there any way to grab\n> > the .git/hooks files as part of the clone (or pull)?\n>\n> No. You can add the appropriate instructions to instructions how to\n> clone the repository, users have to install the hooks manually.\n>\n> Now I went on with a large writeup on considerations for implementing\n> such a feature (including security), but then I scrapped it. What would\n> you like to use these hooks for? Really, perhaps it's best to instead do\n> any \"post-commit\" etc. checks at the push time instead of the commit\n> time, so that developers can still freely commit locally, e.g. I\n> sometimes do temporary commits on side branches of various work in\n> progress changes, then randomly merge them together etc. before I come\n> up with the final sequence of commits that I push out.\n\nI've not done it for myself yet, but I had an idea about making an independent \nbranch in the repository itself containing the hook scripts for that project. \nThat way, the cloners get the scripts but still have to knowingly install \nthem themselves.\n\nIf you were feeling particularly brave, you could check that branch out \nin .git/hooks.\n\n\nAndy\n\n\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"51791","messageId":"20070829095202.GE1219@pasky.or.cz","threadId":"9685","inReplyTo":"200708291005.08795.andyparkins@gmail.com","subject":"Re: cloning/pulling hooks","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-08-29T09:52:02Z","receivedAt":"2007-08-29T09:52:02Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Wed, Aug 29, 2007 at 11:05:07AM CEST, Andy Parkins wrote:\n> On Tuesday 2007 August 28, Petr Baudis wrote:\n> \n> > On Tue, Aug 28, 2007 at 06:46:48PM CEST, Josh England wrote:\n> > > When cloning an existing repository, is there any way to grab\n> > > the .git/hooks files as part of the clone (or pull)?\n> >\n> > No. You can add the appropriate instructions to instructions how to\n> > clone the repository, users have to install the hooks manually.\n> >\n> > Now I went on with a large writeup on considerations for implementing\n> > such a feature (including security), but then I scrapped it. What would\n> > you like to use these hooks for? Really, perhaps it's best to instead do\n> > any \"post-commit\" etc. checks at the push time instead of the commit\n> > time, so that developers can still freely commit locally, e.g. I\n> > sometimes do temporary commits on side branches of various work in\n> > progress changes, then randomly merge them together etc. before I come\n> > up with the final sequence of commits that I push out.\n> \n> I've not done it for myself yet, but I had an idea about making an independent \n> branch in the repository itself containing the hook scripts for that project. \n> That way, the cloners get the scripts but still have to knowingly install \n> them themselves.\n> \n> If you were feeling particularly brave, you could check that branch out \n> in .git/hooks.\n\nYes, that was one of my ideas as well; but one thing is that you may\nwant different hooks scripts for different branches or even different\ntimes in a particular branch. So maybe .git-hooks/, with each change\nprinting a bit fat warning and setting -x. On the other hand maybe it\nmight be simpler to do the tests for which branch/commit are you working\non in the hooks themselves.\n\nBut overally, I'm still not convinced that there is a feasible use-case\nfor the cloned hooks at all. Someone has a particular example?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nEarly to rise and early to bed makes a male healthy and wealthy and dead.\n -- James Thurber\n"},{"id":"51813","messageId":"200708291356.33126.andyparkins@gmail.com","threadId":"9685","inReplyTo":"20070829095202.GE1219@pasky.or.cz","subject":"Re: cloning/pulling hooks","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-08-29T12:56:32Z","receivedAt":"2007-08-29T12:56:32Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 2007 August 29, Petr Baudis wrote:\n\n> But overally, I'm still not convinced that there is a feasible use-case\n> for the cloned hooks at all. Someone has a particular example?\n\nHits me all the time.\n\n1) Start a new project\n2) Install a pre-commit hook that checks that every patch meets some\n arbitrary coding standard\n3) Clone to laptop\n4) Kick self the first time you make a commit that doesn't adhere to coding\n standards that would have been enforced by the hook script.\n\nThe problem is that my brain thinks that cloning gets me the same \nconfiguration as the source, but obviously it doesn't and I forget that I \nneed to clone _then_ scp .git/config and .git/hooks/*.\n\nI understand that these things are a security risk to do automatically, and I \ndon't think I'd advocate that. However, it would be useful to be able to \ngrab those files as well.\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"51815","messageId":"b3889dff0708290618s79cffdb5nb6cc69d14efa8b9@mail.gmail.com","threadId":"9685","inReplyTo":"20070829095202.GE1219@pasky.or.cz","subject":"Re: cloning/pulling hooks","fromName":"Benjamin Collins","fromEmail":"aggieben@gmail.com","sentAt":"2007-08-29T13:18:47Z","receivedAt":"2007-08-29T13:18:47Z","isPatch":false,"sender":{"key":"aggieben@gmail.com","avatar":"https://gravatar.com/avatar/28fe19679c681bd9e42efa676b04199512aab92373ebc94e67537e14663b8d8a?d=mp&s=160"},"body":"On 8/29/07, Petr Baudis wrote:\n> But overally, I'm still not convinced that there is a feasible use-case\n> for the cloned hooks at all. Someone has a particular example?\n>\n> --\n> Petr \"Pasky\" Baudis\n\nMy group at work would like this capability. We have a homogeneous\nenvironment with well-known NFS shares, and some scripts that do\nthings in this common environment (e.g., release scripts). It would\nbe nice if when we do a clone, all the hook scripts (that would be\nvalid on any machine, in any directory, for any user) would come with\nit.\n\nOf course, I understand why it's not already like that, particularly\ngiven the context of Linux development practices. Still - there are\nthose of us that think this would be a great convenience. Having an\noption to git-clone to retrieve the parent's hook scripts would be\npreferable, and have git-clone just disable them by default.\n'git-clone -t repo' or some such.\n\n-- \nBenjamin A. Collins \nhttp://bloggoergosum.us\n"},{"id":"51816","messageId":"Pine.LNX.4.64.0708291421060.28586@racer.site","threadId":"9685","inReplyTo":"200708291356.33126.andyparkins@gmail.com","subject":"Re: cloning/pulling hooks","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-29T13:21:41Z","receivedAt":"2007-08-29T13:21:41Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 29 Aug 2007, Andy Parkins wrote:\n\n> On Wednesday 2007 August 29, Petr Baudis wrote:\n> \n> > But overally, I'm still not convinced that there is a feasible use-case\n> > for the cloned hooks at all. Someone has a particular example?\n> \n> Hits me all the time.\n> \n> 1) Start a new project\n> 2) Install a pre-commit hook that checks that every patch meets some\n> arbitrary coding standard\n> 3) Clone to laptop\n> 4) Kick self the first time you make a commit that doesn't adhere to coding\n> standards that would have been enforced by the hook script.\n\nFor me it is\n\n4) put the check into the Makefile where it belongs.\n\nCiao,\nDscho\n"},{"id":"51818","messageId":"20070829133900.GH1219@pasky.or.cz","threadId":"9685","inReplyTo":"b3889dff0708290618s79cffdb5nb6cc69d14efa8b9@mail.gmail.com","subject":"Re: cloning/pulling hooks","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-08-29T13:39:00Z","receivedAt":"2007-08-29T13:39:00Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Wed, Aug 29, 2007 at 03:18:47PM CEST, Benjamin Collins wrote:\n> On 8/29/07, Petr Baudis wrote:\n> > But overally, I'm still not convinced that there is a feasible use-case\n> > for the cloned hooks at all. Someone has a particular example?\n> >\n> > --\n> > Petr \"Pasky\" Baudis\n> \n> My group at work would like this capability. We have a homogeneous\n> environment with well-known NFS shares, and some scripts that do\n> things in this common environment (e.g., release scripts). It would\n> be nice if when we do a clone, all the hook scripts (that would be\n> valid on any machine, in any directory, for any user) would come with\n> it.\n\nUnfortunately, you didn't really describe a use-case, you just said that\nyou would like them - not what you would use them to. The thing is, so\nfar almost all the use cases would be better off with either using the\nhooks only at the central repository hub and keeping the developers'\nfreedom locally, or would work better simply somewhere else than in hook\nfiles. I'm not saying that this must be the case every time, that is why\nI'm asking for more input data.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nEarly to rise and early to bed makes a male healthy and wealthy and dead.\n -- James Thurber\n"},{"id":"51820","messageId":"Pine.LNX.4.64.0708291446011.28586@racer.site","threadId":"9685","inReplyTo":"b3889dff0708290618s79cffdb5nb6cc69d14efa8b9@mail.gmail.com","subject":"Re: cloning/pulling hooks","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-29T13:49:45Z","receivedAt":"2007-08-29T13:49:45Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 29 Aug 2007, Benjamin Collins wrote:\n\n> Of course, I understand why it's not already like that, particularly \n> given the context of Linux development practices.\n\nIt has nothing to do with Linux development practices. There are \nfundamental reasons why we don't fetch hooks:\n\n- they are _not_ part of the repository; just look at the \n .gitattributes-in-the-index-but-not-worktree issue to find out why,\n\n- it is _private_ data, just like the config. The client has _no \n business_ to read them, let alone fetch them,\n\n- if you have the hooks on different machines, chances are that you need a \n mechanism to update the hooks... This naturally suggests putting the \n hooks into their own branch.\n\nProbably there are way more reasons not to allow such a thing as fetching \nhooks.\n\nCiao,\nDscho\n"},{"id":"51821","messageId":"20070829135441.GI10749@pasky.or.cz","threadId":"9685","inReplyTo":"Pine.LNX.4.64.0708291446011.28586@racer.site","subject":"Re: cloning/pulling hooks","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-08-29T13:54:41Z","receivedAt":"2007-08-29T13:54:41Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":" Hi,\n\nOn Wed, Aug 29, 2007 at 03:49:45PM CEST, Johannes Schindelin wrote:\n> On Wed, 29 Aug 2007, Benjamin Collins wrote:\n> \n> > Of course, I understand why it's not already like that, particularly \n> > given the context of Linux development practices.\n> \n> It has nothing to do with Linux development practices. There are \n> fundamental reasons why we don't fetch hooks:\n> \n> - they are _not_ part of the repository; just look at the \n> .gitattributes-in-the-index-but-not-worktree issue to find out why,\n> \n> - it is _private_ data, just like the config. The client has _no \n> business_ to read them, let alone fetch them,\n> \n> - if you have the hooks on different machines, chances are that you need a \n> mechanism to update the hooks... This naturally suggests putting the \n> hooks into their own branch.\n> \n> Probably there are way more reasons not to allow such a thing as fetching \n> hooks.\n\n these are all really just technical details - if we decided that it\n_is_ useful to have a mechanism to manage hooks, it really is no problem\nto introduce some easy-to-use automated way to keep .git/hooks/ updated\nbased on some head, have .git-hooks/ as part of your current branch, or\nwhatever. And of course, \"fetching hooks\" may not (and very frequently\nyou wouldn't ever want it to) mean \"grabbing the same hooks the server\nuses\".\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nEarly to rise and early to bed makes a male healthy and wealthy and dead.\n -- James Thurber\n"},{"id":"51822","messageId":"Pine.LNX.4.64.0708291502340.28586@racer.site","threadId":"9685","inReplyTo":"20070829135441.GI10749@pasky.or.cz","subject":"Re: cloning/pulling hooks","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-29T14:06:17Z","receivedAt":"2007-08-29T14:06:17Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 29 Aug 2007, Petr Baudis wrote:\n\n> On Wed, Aug 29, 2007 at 03:49:45PM CEST, Johannes Schindelin wrote:\n> > On Wed, 29 Aug 2007, Benjamin Collins wrote:\n> > \n> > > Of course, I understand why it's not already like that, particularly \n> > > given the context of Linux development practices.\n> > \n> > It has nothing to do with Linux development practices. There are \n> > fundamental reasons why we don't fetch hooks:\n> > \n> > - they are _not_ part of the repository; just look at the \n> > .gitattributes-in-the-index-but-not-worktree issue to find out why,\n> > \n> > - it is _private_ data, just like the config. The client has _no \n> > business_ to read them, let alone fetch them,\n> > \n> > - if you have the hooks on different machines, chances are that you need a \n> > mechanism to update the hooks... This naturally suggests putting the \n> > hooks into their own branch.\n> > \n> > Probably there are way more reasons not to allow such a thing as fetching \n> > hooks.\n> \n> these are all really just technical details - if we decided that it\n> _is_ useful to have a mechanism to manage hooks, it really is no problem\n> to introduce some easy-to-use automated way to keep .git/hooks/ updated\n> based on some head, have .git-hooks/ as part of your current branch, or\n> whatever. And of course, \"fetching hooks\" may not (and very frequently\n> you wouldn't ever want it to) mean \"grabbing the same hooks the server\n> uses\".\n\nI think that they are way more than just technical issues: the \nchicken-and-egg problem is certainly _not_ a technical issue.\n\nBesides, another very valid issue is that of portability. Hooks can be \n_any_ executables. Not just scripts. Not just _bash_ scripts.\n\nThe other issue I raised, however, seemed to die away in the other noise:\n\n_Why_ on earth do you want to put something into the SCM specific \nmeta-data which should be part of the build process _to begin with_?\n\n_All_ of the arguments I read are along the lines \"we want to enforce some \ncoding styles\" or similar. These issues are _orthogonal_ to the question \nwhich SCM is used.\n\nCiao,\nDscho\n"},{"id":"51826","messageId":"20070829141948.GJ10749@pasky.or.cz","threadId":"9685","inReplyTo":"Pine.LNX.4.64.0708291502340.28586@racer.site","subject":"Re: cloning/pulling hooks","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-08-29T14:19:49Z","receivedAt":"2007-08-29T14:19:49Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Wed, Aug 29, 2007 at 04:06:17PM CEST, Johannes Schindelin wrote:\n> I think that they are way more than just technical issues: the \n> chicken-and-egg problem is certainly _not_ a technical issue.\n\nWhat do you mean by the chicken-and-egg problem? I think I missed that.\n\n> Besides, another very valid issue is that of portability. Hooks can be \n> _any_ executables. Not just scripts. Not just _bash_ scripts.\n\nSo? That's really up to whoever maintains the repository to sort out.\n\n> The other issue I raised, however, seemed to die away in the other noise:\n> \n> _Why_ on earth do you want to put something into the SCM specific \n> meta-data which should be part of the build process _to begin with_?\n> \n> _All_ of the arguments I read are along the lines \"we want to enforce some \n> coding styles\" or similar. These issues are _orthogonal_ to the question \n> which SCM is used.\n\nYour company has certain rules on how all the source on the public\nbranches should look like, etc. It's not quite clear to me how can build\nsystem enforce these rules.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nEarly to rise and early to bed makes a male healthy and wealthy and dead.\n -- James Thurber\n"},{"id":"51827","messageId":"200708291528.31599.andyparkins@gmail.com","threadId":"9685","inReplyTo":"Pine.LNX.4.64.0708291421060.28586@racer.site","subject":"Re: cloning/pulling hooks","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-08-29T14:28:30Z","receivedAt":"2007-08-29T14:28:30Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 2007 August 29, Johannes Schindelin wrote:\n\n> > 1) Start a new project\n> > 2) Install a pre-commit hook that checks that every patch meets some\n> > arbitrary coding standard\n> > 3) Clone to laptop\n> > 4) Kick self the first time you make a commit that doesn't adhere to\n> > coding standards that would have been enforced by the hook script.\n>\n> For me it is\n>\n> 4) put the check into the Makefile where it belongs.\n\nI suppose you are right, the reason I pick the hook is because I don't mind \nhaving untidy code in the working tree but don't want it in the repository. \n\nAlso, it was given as an example hook so I enabled it :-)\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"51828","messageId":"Pine.LNX.4.64.0708291529010.28586@racer.site","threadId":"9685","inReplyTo":"20070829141948.GJ10749@pasky.or.cz","subject":"Re: cloning/pulling hooks","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-29T14:31:29Z","receivedAt":"2007-08-29T14:31:29Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 29 Aug 2007, Petr Baudis wrote:\n\n> On Wed, Aug 29, 2007 at 04:06:17PM CEST, Johannes Schindelin wrote:\n> > I think that they are way more than just technical issues: the \n> > chicken-and-egg problem is certainly _not_ a technical issue.\n> \n> What do you mean by the chicken-and-egg problem? I think I missed that.\n\nWhat if hooks/update is in your set? It _does not_ run before it is \nchecked out, but of course, some ref is updated before it is checked out.\n\n> > _All_ of the arguments I read are along the lines \"we want to enforce \n> > some coding styles\" or similar. These issues are _orthogonal_ to the \n> > question which SCM is used.\n> \n> Your company has certain rules on how all the source on the public \n> branches should look like, etc. It's not quite clear to me how can build \n> system enforce these rules.\n\nThe same as a hook. You just put the check into the Makefile.\n\nCiao,\nDscho\n"},{"id":"51829","messageId":"20070829144135.GI1219@pasky.or.cz","threadId":"9685","inReplyTo":"Pine.LNX.4.64.0708291529010.28586@racer.site","subject":"Re: cloning/pulling hooks","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-08-29T14:41:35Z","receivedAt":"2007-08-29T14:41:35Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Hi!\n\nOn Wed, Aug 29, 2007 at 04:31:29PM CEST, Johannes Schindelin wrote:\n> On Wed, 29 Aug 2007, Petr Baudis wrote:\n> \n> > On Wed, Aug 29, 2007 at 04:06:17PM CEST, Johannes Schindelin wrote:\n> > > I think that they are way more than just technical issues: the \n> > > chicken-and-egg problem is certainly _not_ a technical issue.\n> > \n> > What do you mean by the chicken-and-egg problem? I think I missed that.\n> \n> What if hooks/update is in your set? It _does not_ run before it is \n> checked out, but of course, some ref is updated before it is checked out.\n\nThe hook may depend on some other data checked out as well etc., so I\nthink the simple sane solution is to use the new update hook only for\nthe next update; this should match users' expectations as well.\n\nBut we got into discussing the details before the fundamentals. :-)\n\n> > > _All_ of the arguments I read are along the lines \"we want to enforce \n> > > some coding styles\" or similar. These issues are _orthogonal_ to the \n> > > question which SCM is used.\n> > \n> > Your company has certain rules on how all the source on the public \n> > branches should look like, etc. It's not quite clear to me how can build \n> > system enforce these rules.\n> \n> The same as a hook. You just put the check into the Makefile.\n\nHow exactly does the Makefile affect what does and what does not get\nchecked in?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nEarly to rise and early to bed makes a male healthy and wealthy and dead.\n -- James Thurber\n"},{"id":"51830","messageId":"Pine.LNX.4.64.0708291555450.28586@racer.site","threadId":"9685","inReplyTo":"20070829144135.GI1219@pasky.or.cz","subject":"Re: cloning/pulling hooks","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-08-29T14:56:32Z","receivedAt":"2007-08-29T14:56:32Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 29 Aug 2007, Petr Baudis wrote:\n\n> On Wed, Aug 29, 2007 at 04:31:29PM CEST, Johannes Schindelin wrote:\n>\n> > Pasky wrote:\n> >\n> > > Your company has certain rules on how all the source on the public \n> > > branches should look like, etc. It's not quite clear to me how can \n> > > build system enforce these rules.\n> > \n> > The same as a hook. You just put the check into the Makefile.\n> \n> How exactly does the Makefile affect what does and what does not get \n> checked in?\n\nBy refusing to compile when something's not right?\n\nCiao,\nDscho\n"},{"id":"51845","messageId":"7vlkbup1kh.fsf@gitster.siamese.dyndns.org","threadId":"9685","inReplyTo":"b3889dff0708290618s79cffdb5nb6cc69d14efa8b9@mail.gmail.com","subject":"Re: cloning/pulling hooks","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-29T19:45:18Z","receivedAt":"2007-08-29T19:45:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Benjamin Collins\" writes:\n\n> On 8/29/07, Petr Baudis wrote:\n>> But overally, I'm still not convinced that there is a feasible use-case\n>> for the cloned hooks at all. Someone has a particular example?\n>>\n>> --\n>> Petr \"Pasky\" Baudis\n>\n> My group at work would like this capability. We have a homogeneous\n> environment with well-known NFS shares, and some scripts that do\n> things in this common environment (e.g., release scripts). It would\n> be nice if when we do a clone, all the hook scripts (that would be\n> valid on any machine, in any directory, for any user) would come with\n> it.\n>\n> Of course, I understand why it's not already like that, particularly\n> given the context of Linux development practices. Still - there are\n> those of us that think this would be a great convenience. Having an\n> option to git-clone to retrieve the parent's hook scripts would be\n> preferable, and have git-clone just disable them by default.\n> 'git-clone -t repo' or some such.\n\nI do think this is project specific, as such:\n\n - you can have .git/hooks be a symlink to ../git-hooks/\n (i.e. the project toplevel \"git-hooks\" directory, or\n whereever the project finds convenient);\n\n - have \"git-hooks\" tracked\n\nThe latter will take care of the distribution issue. Now, we\nwould need a generic and convenient way to make sure that the\nnew repository \"clone\" makes has .git/hooks as a symlink to\nwhereever in-tree that follows the project convention. I think\nyou could use the existing templates mechanism. Allow \"git\nclone\" to take 'template=' parameter and pass it down to \"git\ninit\" it invokes. You use project specific template that\narranges the .git/hooks/ symlink when you clone. We could even\nsupport \"[clone] template = this/template/file\" variable in your\n$HOME/.gitconfig if we go this route.\n\n \n"},{"id":"51848","messageId":"20070829202726.GC11824@steel.home","threadId":"9685","inReplyTo":"200708291356.33126.andyparkins@gmail.com","subject":"Re: cloning/pulling hooks","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-08-29T20:27:26Z","receivedAt":"2007-08-29T20:27:26Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Andy Parkins, Wed, Aug 29, 2007 14:56:32 +0200:\n> On Wednesday 2007 August 29, Petr Baudis wrote:\n> \n> > But overally, I'm still not convinced that there is a feasible use-case\n> > for the cloned hooks at all. Someone has a particular example?\n> \n> Hits me all the time.\n> \n> 1) Start a new project\n> 2) Install a pre-commit hook that checks that every patch meets some\n> arbitrary coding standard\n> 3) Clone to laptop\n> 4) Kick self the first time you make a commit that doesn't adhere to coding\n> standards that would have been enforced by the hook script.\n> \n> The problem is that my brain thinks that cloning gets me the same \n> configuration as the source, but obviously it doesn't and I forget that I \n> need to clone _then_ scp .git/config and .git/hooks/*.\n> \n> I understand that these things are a security risk to do automatically, and I \n> don't think I'd advocate that. However, it would be useful to be able to \n> grab those files as well.\n\nIt is just a case for \"git clone --clone-templates\" (which does not\nexist yet), not for a clone hook.\n\nSometimes, I miss the cloning of .git/description, it probably should\nbe something like: \"git clone --clone=templates,config,description\".\nWhere config could include a predefined set of harmless config options\n(like colors or i18n).\n"},{"id":"51850","messageId":"20070829203543.GD11824@steel.home","threadId":"9685","inReplyTo":"Pine.LNX.4.64.0708291555450.28586@racer.site","subject":"Re: cloning/pulling hooks","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-08-29T20:35:43Z","receivedAt":"2007-08-29T20:35:43Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Johannes Schindelin, Wed, Aug 29, 2007 16:56:32 +0200:\n> > > > Your company has certain rules on how all the source on the public \n> > > > branches should look like, etc. It's not quite clear to me how can \n> > > > build system enforce these rules.\n> > > \n> > > The same as a hook. You just put the check into the Makefile.\n> > \n> > How exactly does the Makefile affect what does and what does not get \n> > checked in?\n> \n> By refusing to compile when something's not right?\n> \n\nHow do I \"compile\" that pile of .docs which they called \"project\ndocumentation\"?\n\nI really do feel for people working for corporate projects: the rules\nare strict (and often stupid) and there are mistakes and punishment\nfor them. You really don't want to make a merge of a branch containing\ncommits where description is in wrong format (or wrong content,\nbecause the customer may see it, and one of the greate rules of\nbussiness seem to be \"hide and obscure\").\n\nPeople prefer to avoid mistakes from happening, then having to correct\nthem (and yes, they do and will commit without doing sanity check).\n\nSo I think Pasky has a valid point\n"}]}