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

[Pang Yan Han <pangyanhan@gmail.com>]

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