Re: receive.denyCurrentBranch=updateInstead updates working tree even when receive.denyNonFastForwards rejects push

[Junio C Hamano <gitster@pobox.com>]

Rajesh Madamanchi <rmadamanchi@gmail.com> writes:

> Hi, I am looking to report the below behavior when seems incorrect to
> me when receive.denyCurrentBranch is set to updateInstead and
> receive.denyNonFastForwards is set to true.

It seems that we took a lazy but incorrect route while adding the
DENY_UPDATE_INSTEAD hack to builtin/receive-pack.c::update() and new
code went to a wrong place in a series of checks.  Everythng else in
the same switch() statement either refuses or just decides to let
later step to update without taking actual action, so that later
checks such as "the new tip commit must have been transferred", "the
new tip must be a fast-forward of the old tip", etc., but the one
for DENY_UPDATE_INSTEAD immediately calls update_worktree() there.
It should be changed to decide to later call the function when
everybody else in the series of checks agrees that it is OK to let
this push accepted, and then the actual call is made somewhere near
where we call run_update_hook(), probably after the hook says it is
OK to update.