Re: [PATCH 2/2] send-pack: check atomic push before running GPG
- From
Jiang Xin <worldhello.net@gmail.com>
- Date
- Sep 16, 2020, 01:53 UTC
- Message-ID
- <CANYiYbHYi70ZcjDTyQ++_+njuZMF=TksPepH+wP+zNmhBABNAg@mail.gmail.com>
- In-Reply-To
- <xmqqmu1qzrbo.fsf@gitster.c.googlers.com>
Junio C Hamano <gitster@pobox.com> 于2020年9月16日周三 上午5:08写道:
Show 21 quoted lines
> > 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.
Show 7 quoted lines
> > > - 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.
Show 21 quoted lines
> > - > > - 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.