Re: [PATCH/RFC 0/2] Teach receive-pack not to run update hook for corrupt/non existent ref

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 27, 2011, 00:04 UTC
Message-ID: <7vd3emzw8n.fsf@alter.siamese.dyndns.org>
In-Reply-To: <7voby6zwxg.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 14 quoted lines

> Sitaram Chamarty <sitaramc@gmail.com> writes:
>
>>> 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?
>
> In case it was unclear, I was trying to say the hooks should not run with
> empty input.

If the purpose of "post-update" (or "post-receive") hooks were to trigger every time anybody attempted to push into the repository, then it would make perfect sense for them to trigger when "push origin :no-such-branch" were attempted. But if that were the purpose of these hooks, they should also trigger when "push origin master" is run and "master" is already at the right commit, as that is the same kind of no-op -- the pushed into repository was already up-to-date with respect to the wish of the pusher.

I do not mind, and I do prefer, these hooks to run when somebody deleted an existing ref that points at a corrupt or non-existent object, as that is _not_ a no-op but is a meaningful event that has an effect that is observable from the outside world (e.g. ls-remote).