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