git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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.

Previous: Junio C HamanoNext: Junio C Hamano
Message 5 of 17 in “t5534: new test case for atomic signed push”
  1. 1/2 t5534: new test case for atomic signed pushHan Xin, Sep 15, 2020
  2. 2/2 send-pack: check atomic push before running GPGHan Xin, Sep 15, 2020
  3. Junio C HamanoSep 15, 2020
  4. Junio C HamanoSep 15, 2020
  5. Jiang XinSep 16, 2020
  6. Junio C HamanoSep 16, 2020
  7. 韩欣(炽天)Sep 16, 2020
  8. Jiang XinSep 16, 2020
  9. Junio C HamanoSep 16, 2020
  10. send-pack: run GPG after atomic push checkingHan Xin, Sep 18, 2020
  11. Junio C HamanoSep 19, 2020
  12. send-pack: run GPG after atomic push checkingHan Xin, Sep 19, 2020
  13. Junio C HamanoSep 19, 2020
  14. send-pack: run GPG after atomic push checkingHan Xin, Sep 20, 2020
  15. Junio C HamanoSep 15, 2020
  16. brian m. carlsonSep 16, 2020
  17. Junio C HamanoSep 15, 2020

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.