On Fri, Aug 14, 2015 at 7:10 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Dave Borowitz <dborowitz@xxxxxxxxxx> 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 <dborowitz@xxxxxxxxxx> >> --- >> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html