Re: [PATCH 2/2] send-pack: check atomic push before running GPG

[Jiang Xin <worldhello.net@gmail.com>]

Junio C Hamano <gitster@pobox.com> 于2020年9月16日周三 上午5:08写道：
>
> Han Xin <chiyutianyi@gmail.com> writes:
>
> > Atomic push may be rejected, which makes it meanigless to generate push
> > cert first. Therefore, the push cert generation was moved after atomic
> > check.
>
> The overstatement "may be rejected" is probably a bit misleading the
> readers and reviewers.  REF_STATUS_REJECT_NONFASTFORWARD may be
> observed by check_to_send_update() but the reason is set in
> set_ref_status_for_push(), which locally decides not to propose a
> no-ff ref update to the other side.  At this point of the control
> flow, the other side hasn't have a chance to reject the push,
> because "we want you to update these refs to these new values" is
> yet to be sent (it is done after composing the push certificate).
>
>     We may decide not to push (e.g. their ref may not fast forward
>     to what we are pushing) at this point in the code.  Checking the
>     condition first will save us to ask GPG to sign the push
>     certificate, since we will not send it to the other side.
>

It's always hard for a new contributor to write a decent commit log message.

>
> > -     if (!args->dry_run)
> > -             advertise_shallow_grafts_buf(&req_buf);
>
> Why should this be moved?  It doesn't seem to have anything to do
> with the push certificate.
>

Checking the condition first will also save us to prepare shallow advertise.

> > -
> > -     if (!args->dry_run && push_cert_nonce)
> > -             cmds_sent = generate_push_cert(&req_buf, remote_refs, args,
> > -                                            cap_buf.buf, push_cert_nonce);
> > -
> >       /*
> >        * Clear the status for each ref and see if we need to send
> >        * the pack data.
>
> This "Clear the status for each ref" worries me.
>
> The generate_push_cert() function RELIES on ref->status and filters
> out the ref that failed to pass the local check from the generated
> push certificate.  If you let the loop (post context of this hunk)
> run, ref->status will be updated by it, so the net effect of this
> patch is that it breaks "non-atomic" case that pushes multiple refs
> and one of ref fails to pass the local check.
>
> IOW, generate_push_cert() MUST be called before this loop "clears
> the status for each ref" by assigning to ref->status.
>

The next block ("Finally, tell the other end!") is what we send
commands to "receive-pack", right after some of the status are reset
to REF_STATUS_OK or REF_STATUS_EXPECTING_REPORT by this chunk of code.
So moving the generate_push_cert() part right before the "Finally,
tell the other end!" part LGTM.