From: Sitaram Chamarty Date: Mon, 26 Sep 2011 23:44:02 GMT Subject: Re: [PATCH/RFC 0/2] Teach receive-pack not to run update hook for corrupt/non existent ref Message-ID: In-Reply-To: <7vwrcuzy44.fsf@alter.siamese.dyndns.org> On Tue, Sep 27, 2011 at 4:53 AM, Junio C Hamano wrote: > Sitaram Chamarty writes: > >> From a philosophical point of view, update and pre-receive *check* >> things to make sure everything is OK.  IMO they should be allowed to >> run even if the ref being deleted doesn't exist -- that could well be >> an error condition that the guy who owns the repo wants to trap and >> alert himself to in some special way.  I would *not* like them >> disabled. > > I think this is a sane thing to do. > >> Post-{update,receive} are for *after* a successful push.  My >> suggestion would be to make sure the inputs supplied to those hooks >> (via STDIN for post-receive, and as arguments in case of post-update) >> reflect this -- only successfully updated refs are sent in as args. > > Perhaps sane. > >> This might mean that in the case of 'git push origin >> :refs/heads/non-existent-ref' the post-receive hook would run but >> STDIN would be empty, and post-update would run but have no arguments. > > Hmm? > > In that case (if "non-existent-ref" was indeed non-existent, and not just > pointing at a dangling commit), I would say the post anything hook should > not be called for that ref.  These hooks of course need to run if there > are _other_ refs that were updated, though, to handle these _other_ refs, > but I do not think they should be told about the no-op. Question is what happens if none of them existed. It's a difference between not calling the hook at all, versus calling it with no arguments/empty stdin (as the case may be) -- which would you do? I say the hook *should* always run, and the code inside the hook should take care of the fact that no arguments/no input means nothing actually happened. -- Sitaram