Karthik Nayak <karthik.188@xxxxxxxxx> writes: >> In any case, if the actual ref updates and the reported ref updates >> result can be made different, somebody then needs to step in and >> reconcile the inconsistencies, no? > > Naturally, the server is in charge of that, this is similar with the > pre-receive or proc-receive hooks. In that aspects this is very similar > to the proc-receive hook which transfers the responsibility of updating > refs to the owner of the hook. I am afraid that my point probably did not come across clearly. I am talking about the repository on the user's local workstation from which 'git push' was run. The server reported that the push failed, so the remote-tracking branches in the local repository reflect that the push did not succeed. In reality, however, the ref transaction was already committed on the server. When the user runs 'git fetch' after the failed 'git push' returns, they may see that the server actually accepted the update. The server cannot be "in charge" of that, as it is incapable of resolving this discrepancy. Only the user, by choosing to fetch again, can reconcile local state with the server. >> The way pusher perceives the state of their remote repository they >> just pushed to, which they learn from the output of receive-report >> hook, would have no link to reality when this hook is used on the >> remote side. This may matter because the "git push" updates its own >> remote-tracking branches to match what the remote says (i.e., >> pretends as if "git push" was immediately followed by "git fetch" to >> the same remote). > > For remote tracking, that's exactly the conservative behavior we want > from the hook. When the hook reports 'ng', the client does not update > the reference to a new value, meaning the push did not happen and that > is what we want to convey. But still the server side did already commit the ref transaction so the update has been made. Here is how the proposed commit log message explained this: >>> Note that in either failure mode, ref updates already applied by >>> execute_commands() are not rolled back. The hook can cause the client >>> to perceive the push as failed, but cannot undo server-side changes.