Re: [PATCH 5/5] Teach receive-pack to run pre-receive/post-receive hooks

From: Shawn O. Pearce <spearce@spearce.org>
Date: Mar 8, 2007, 03:34 UTC
Message-ID: <20070308033434.GA29567@spearce.org>
In-Reply-To: <7vbqj4eh9h.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano <junkio@cox.net> wrote:

Show 8 quoted lines

> Linus Torvalds <torvalds@linux-foundation.org> writes:
> 
> > Can you give a concise explanation of how "pre-receive" differ from the 
> > old "update", and how does "post-receive" differ from the old 
> > "post-update"?
> 
> They are somewhat redundant.  They get everything at once,
> unlike update hook.

Also unlike update hook, pre-receive rejects or accepts the entire batch of refs and cannot reject an individual ref update.

I would have removed post-update, but users depend on it. I would have modified its argument structure to be like post-receive, but again, users might depend on the current argument arrangement.

Show 7 quoted lines

> The old interface is adequate to do the same thing if you
> arrange them so that update hook notes which refs (with what old
> sha1 value it had) were asked to be updated, and make your
> post-update hook (which gets the names of refs) notice if some
> of them failed and from what ref a successful update happened.
> But getting everything at once is sometimes easier to work
> with.

Except that doing that is horribly ugly, as there are no locks held by receive-pack to help the hook author, so the hook author must dump that data out to a temporary file and be sure the post-update hook knows which file to look at, which it can't really know... a mess.

-- 
Shawn.