Re: [PATCH] update-hook: remove all functionality that should be in hooks/post-receive

["Shawn O. Pearce" <spearce@spearce.org>]

Andy Parkins <andyparkins@gmail.com> wrote:
> On Saturday 2007, March 24, Francis Moreau wrote:
> 
> > yes that almost would do the thing. But instead of hacking the hook,
> > it would be great to have a trivial setup at the begining of the
> > script to choose this config.
> 
> I'd like Junio's permission before actually doing that; I know he is 
> worried about out-of-control growth of hook scripts and it's already 
> overly large just to do the one job it's got.

One thought I had today:

The old hooks (update, post-update) were easy to chain if you wanted
to run more than one "standard" hook in a repository.  Just pass
"$@" to each hook excutable, using a small shell-script wrapper
that is installed as the actual hook.

The new hooks (pre-receive, post-receive) are not so easy to chain,
as their input comes by way of stdin.  You'd have to copy the
data off to a temporary file, and redirect that into each hook in
turn.  Annoying.

So I'm kicking around the idea of teaching receive-pack to run
hooks in filename order if the hook is actually a subdirectory.
Then you can do:

  mkdir .git/hooks/post-receive
  ln -s \
    ~/git/contrib/email/post-receive-head \
    .git/hooks/post-receive/01-head
  ln -s \
    ~/git/contrib/email/post-receive-tag \
    .git/hooks/post-receive/02-tag
  ln -s \
    ~/git/contrib/continuous/post-receive-cinotify \
    .git/hooks/post-receive/10-cinotify

Where this applies to Andy's message that I quoted is the email
hooks could be split up to handle different types of refs in each
hook, e.g. one for heads and one for tags, and just skip refs that
don't apply to that particular hook.

-- 
Shawn.