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

From: Shawn O. Pearce <spearce@spearce.org>
Date: Mar 25, 2007, 09:25 UTC
Message-ID: <20070325092530.GI25863@spearce.org>
In-Reply-To: <200703251011.53712.andyparkins@gmail.com>

Andy Parkins <andyparkins@gmail.com> wrote:

Show 9 quoted lines

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