Re: [PATCH v5 3/3] hook: introduce the receive-report hook

Karthik Nayak [off-list ref] writes:

quoted

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.

quoted

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:

quoted

quoted

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.