When cloning an existing repository, is there any way to grab
the .git/hooks files as part of the clone (or pull)?

-JE



-

[ message continues ]

Hi,


  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.

-- 
				Petr "Pasky" Baudis
Early to rise and early to bed makes a male healthy and wealthy and dead.
                -- James Thurber
-

[ message continues ]

Thanks Petr.  I think I'll look at using the git clone --template
functionality and just keep my own templates around.

-JE



-

[ message continues ]

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
-

[ message continues ]

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
-

[ message continues ]

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
-

[ message continues ]

Hi,


For me it is

4) put the check into the Makefile where it belongs.

Ciao,
Dscho
-

[ message continues ]

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
-

[ message continues ]

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

-

[ message continues ]

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
-

[ message continues ]

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
-

[ message continues ]

Hi,


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
-

[ message continues ]

Hi,


  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
-

[ message continues ]

Hi,


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

-

[ message continues ]

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
-

[ message continues ]

Hi,


What if hooks/update is in your set?  It _does not_ run before it is 

The same as a hook.  You just put the check into the Makefile.

Ciao,
Dscho

-

[ message continues ]

Hi!


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.


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
-

[ message continues ]

Hi,


By refusing to compile when something's not right?

Ciao,
Dscho

-

[ message continues ]

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

-

[ message continues ]

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.

   
-

[ message continues ]