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, 16:56 UTC
Message-ID: <7vhb3xyld7.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20110927090225.GA1493@myhost>

[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@gmail.com> writes:

Show 5 quoted lines

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