git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Han Xin <chiyutianyi@gmail.com>
Cc: Git List <git@vger.kernel.org>,
	Han Xin <hanxin.hx@alibaba-inc.com>,
	"brian m . carlson" <sandals@crustytoothpaste.net>,
	Jiang Xin <zhiyou.jx@alibaba-inc.com>
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: <xmqqft7eljkz.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <20200918045052.13022-1-hanxin.hx@alibaba-inc.com> (Han Xin's message of "Fri, 18 Sep 2020 12:50:52 +0800")

Han Xin <chiyutianyi@gmail.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

  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 \
    --in-reply-to=xmqqft7eljkz.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=chiyutianyi@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=hanxin.hx@alibaba-inc.com \
    --cc=sandals@crustytoothpaste.net \
    --cc=zhiyou.jx@alibaba-inc.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public 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).