From: Junio C Hamano <email@example.com> To: Han Xin <firstname.lastname@example.org> Cc: Git List <email@example.com>, Han Xin <firstname.lastname@example.org>, "brian m . carlson" <email@example.com>, Jiang Xin <firstname.lastname@example.org> Subject: Re: [PATCH v2] send-pack: run GPG after atomic push checking Date: Fri, 18 Sep 2020 17:02:36 -0700 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> (Han Xin's message of "Fri, 18 Sep 2020 12:50:52 +0800") Han Xin <email@example.com> writes: > The refs update commands can be sent to the server side in two different > ways: GPG-signed or unsigned. We should run these two operations in the > same "Finally, tell the other end!" code block, but they are seperated > by the "Clear the status for each ref" code block. This will result in > a slight performance loss, because the failed atomic push will still > perform unnecessary preparations for shallow advertise and GPG-signed > commands buffers. I am not sure if that is a good justification for this patch. In the context of a push that involves GPG signature, preparation of the buffer contents to be signed can hardly be the performance bottleneck. Also, this change, if sold solely on the basis of performance, is optimizing for the wrong case of the user _failing_ to propose a push that is atomic. The true value I see in this change is that the user won't have to be bothered by the (possible) GPG passphrase input when there is nothing to sign. Let's sell the change as such instead. > Add a new test case to t5534 to ensure GPG will not be called when the > GPG-signed atomic push fails. As I mentioned in the previous round of the review, I am not sure if it is wise to expect that the exact phrasing of error messages like "atomic push failed" and "non-fast-forward" to stay constant and the output format of the "git push" to stay exactly the same in this test. Wouldn't it be more robust to grep for a message that emitted from the error codepath in sign_buffer(), e.g. "gpg failed to sign", in order to ensure absense of the sign that GPG were attempted? The replacement test I have in mind would look like the attached. Thanks. diff --git a/t/t5534-push-signed.sh b/t/t5534-push-signed.sh index 030331f1c5..3eb3642abb 100755 --- a/t/t5534-push-signed.sh +++ b/t/t5534-push-signed.sh @@ -273,4 +273,17 @@ test_expect_success GPGSM 'fail without key and heed user.signingkey x509' ' test_cmp expect dst/push-cert-status ' +test_expect_success GPG 'failed atomic push does not execute GPG' ' + prepare_dst && + git -C dst config receive.certnonceseed sekrit && + write_script gpg <<-EOF && + # should check atomic push locally before running GPG. + exit 1 + EOF + test_must_fail env PATH="$TRASH_DIRECTORY:$PATH" git push \ + --signed --atomic --porcelain \ + dst noop ff noff >out 2>&1 && + test_i18ngrep ! "gpg failed to sign" out +' + test_done
next prev parent reply other threads:[~2020-09-19 0:03 UTC|newest] Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-09-15 9:58 [PATCH 1/2] t5534: new test case for atomic signed push Han Xin 2020-09-15 9:58 ` [PATCH 2/2] send-pack: check atomic push before running GPG Han Xin 2020-09-15 21:02 ` Junio C Hamano 2020-09-15 21:40 ` Junio C Hamano 2020-09-16 1:53 ` Jiang Xin 2020-09-16 4:37 ` Junio C Hamano 2020-09-16 11:49 ` Jiang Xin 2020-09-16 23:44 ` Junio C Hamano 2020-09-18 4:50 ` [PATCH v2] send-pack: run GPG after atomic push checking Han Xin 2020-09-19 0:02 ` Junio C Hamano [this message] 2020-09-19 14:47 ` [PATCH v3] " Han Xin 2020-09-19 23:02 ` Junio C Hamano 2020-09-20 6:20 ` [PATCH v4] " Han Xin 2020-09-16 17:35 ` [PATCH 2/2] send-pack: check atomic push before running GPG 韩欣(炽天) 2020-09-15 20:31 ` [PATCH 1/2] t5534: new test case for atomic signed push Junio C Hamano 2020-09-16 0:34 ` brian m. carlson 2020-09-15 20:34 ` Junio C Hamano
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH v2] send-pack: run GPG after atomic push checking' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).