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

[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 [off-list ref] 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'.