Re: cloning/pulling hooks

Re: cloning/pulling hooks

[Andy Parkins]

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

Re: cloning/pulling hooks

[Petr Baudis]

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

Re: cloning/pulling hooks

[Andy Parkins]

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

Re: cloning/pulling hooks

[Johannes Schindelin]

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

Re: cloning/pulling hooks

[Andy Parkins]

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

Re: cloning/pulling hooks

[Alex Riesen]

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

Re: cloning/pulling hooks

[Benjamin Collins]

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.

-- 
Benjamin A. Collins <aggieben@gmail.com>
http://bloggoergosum.us

Re: cloning/pulling hooks

[Petr Baudis]

On Wed, Aug 29, 2007 at 03:18:47PM CEST, Benjamin Collins wrote:
> 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.

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

Re: cloning/pulling hooks

[Johannes Schindelin]

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

Re: cloning/pulling hooks

[Petr Baudis]

  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

Re: cloning/pulling hooks

[Johannes Schindelin]

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

Re: cloning/pulling hooks

[Petr Baudis]

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

Re: cloning/pulling hooks

[Johannes Schindelin]

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

Re: cloning/pulling hooks

[Petr Baudis]

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

Re: cloning/pulling hooks

[Johannes Schindelin]

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

Re: cloning/pulling hooks

[Alex Riesen]

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

Re: cloning/pulling hooks

[Junio C Hamano]

"Benjamin Collins" <aggieben@gmail.com> writes:

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

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.