Rajesh Madamanchi <rmadamanchi@xxxxxxxxx> 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.
