On Tue, Sep 27, 2011 at 09:56:52AM -0700, Junio C Hamano wrote: > [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.] Sorry, it's due to my lack of familiarity with mutt. > > 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'. Thanks, I will reroll this later. -- 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