On Tue, Sep 27, 2011 at 4:53 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Sitaram Chamarty <sitaramc@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html