[offtopic: where does that annoying M-F-T header come from? It even seems
to be pointless in this case as it lists the same people as are already on
To/Cc/From of the message.]
Pang Yan Han <pangyanhan@xxxxxxxxx> writes:
> Should I reroll this patch with this behaviour:
>
> - Everything as usual for valid ref updates and deletes
> - For deleting corrupt (dangling?) ref, post-receive and post-update hooks
> also receive the same args as per valid update / delete
Suonds sensible.
> - For deleting non-existent refs:
> - post-receive shall have empty stdin for those refs
> - post-update shall have an empty arg for those refs
I do not think these hooks should see names of refs that ended up being a
no-op. If the push is only about attempting to delete a ref that did not
exist, these hooks should not even get called. If there were other refs
that got updated, these hooks have to be called, but they should not be
told about the no-op. IOW
$ git push $there :no-such-ref master:refs/remotes/origin/master
should:
(1) not call the post-* hooks if the refs/remotes/origin/master was
already pointing at the same commit; or
(2) invoke the post-* hooks if refs/remotes/origin/master is updated, but
should tell hooks only about the update of refs/remotes/origin/master.
That is pretty much in line with how a normal attempt to push the same
commit to an already up-to-date ref works. For example, if you:
$ git push $there master next
when 'master' is lagging and 'next' is already up-to-date, post-update and
post-receive hooks run and told only about 'master' and not 'next'.
--
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