From: Dave Borowitz Date: Mon, 17 Aug 2015 18:11:44 GMT Subject: Re: [PATCH 1/7] Documentation/git-push.txt: Document when --signed may fail Message-ID: In-Reply-To: On Fri, Aug 14, 2015 at 7:10 PM, Junio C Hamano wrote: > Dave Borowitz writes: > >> Like --atomic, --signed will fail if the server does not advertise the >> necessary capability. In addition, it requires gpg on the client side. >> >> Signed-off-by: Dave Borowitz >> --- >> Documentation/git-push.txt | 4 +++- >> 1 file changed, 3 insertions(+), 1 deletion(-) >> >> diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt >> index 135d810..f8b8b8b 100644 >> --- a/Documentation/git-push.txt >> +++ b/Documentation/git-push.txt >> @@ -137,7 +137,9 @@ already exists on the remote side. >> GPG-sign the push request to update refs on the receiving >> side, to allow it to be checked by the hooks and/or be >> logged. See linkgit:git-receive-pack[1] for the details >> - on the receiving end. >> + on the receiving end. If the `gpg` executable is not available, >> + or if the server does not support signed pushes, the push will >> + fail. > > Looks good. > > I am wondering if another mode of failure is worth mentioning: `gpg` > available, you have _some_ keys, but signingkey configured does not > match any of the keys. > > Note that I said "am wondering", which is very different from "I > think we should also describe". I think we don't need to go down the path of enumerating all possible ways the operation can fail. There is probably a reasonably concise way to include more possibilities. How about: "If the attempt to sign with `gpg` fails, or if the server does not support signed pushes, the push will fail." This should cover gpg not being found, gpg being fatally misconfigured, crazy unexpected pipe closures, etc. > Thanks.