On 28.11.2021 15:20, Junio C Hamano wrote:
Fabian Stelzer <fs@xxxxxxxxxxxx> writes:
Hi everyone,
the `signing git objects with ssh` series was released with 2.34 and
i'd like to thank everyone for your support and the good reviews!
I think it would be beneficial now to adjust some of the wording in
flags and the config. Currently everything is configured via gpg.* and
all the `please sign this` flags are named --(no-?)gpg-sign.
I would be in favor of a more generic flag independent of the signing
mechanism. Adding something like `--ssh-sign` would suggest that you'd
be able to switch signing format with it which i think would not be
terribly useful. If you need to use multiple signing mechanism those
would usually be configured per repository and can easily be done with
an `includeif gitdir:` in your config.
Therefore i would suggest just adding a generic `--(no-?)sign` to all
the commands that support gpg-sign right now. The only problem i see
is a conflict with `--signoff` so i'm open to other naming ideas. The
same goes for the config. `sign.` as an alias to `gpg.` would work
well with the current settings.
Let me know what you think and i could prepare a first patch for one
command to see what the alias / config / docs change could look like.
I do share your worry about --sign to be confused with the sign-off
procedure, and that was why the original used --gpg-sign. We are
extending "gpg" part because "gpg" is not the only cryptographic
signing protocol we support, so perhaps --crypto-sign would still be
in the orginal spirit of "This is different from the sign-off, but
is a cryptographic signature, but it is a mouthful.
Even if it's a bit much, including the word crypto makes it quite clear what
the flag does. This is how this could look for `git commit`. I would do
something similar for the `gpg.` configs and alias them with `cryptoSign.`
If this diff is acceptable i can prepare a patch series for all the commands
and the config. Not sure if we want to mark the gpg options as deprecated.
The problem is that the flags could imply that gpg is used even if another
format is configured.
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 6c60bf98f9..67fc77dc1b 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -387,13 +387,18 @@ changes to tracked files.
default commit message.
-S[<keyid>]::
+--crypto-sign[=<keyid>]::
+--no-crypto-sign::
--gpg-sign[=<keyid>]::
--no-gpg-sign::
- GPG-sign commits. The `keyid` argument is optional and
+ Cryptographically sign commits. The `keyid` argument is optional and
defaults to the committer identity; if specified, it must be
- stuck to the option without a space. `--no-gpg-sign` is useful to
+ stuck to the option without a space. `--no-crypto-sign` is useful to
countermand both `commit.gpgSign` configuration variable, and
- earlier `--gpg-sign`.
+ earlier `--crypto-sign`.
+ `--(no-)gpg-sign` is a compatibility alias and has no effect on which
+ cryptographic format will be used. This is determined by the
+ configuration variable cryptoSign.format (see linkgit:git-config[1]).
\--::
Do not interpret any more arguments as options.
diff --git a/builtin/commit.c b/builtin/commit.c
index 883c16256c..2c789ff6f9 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1639,8 +1639,11 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
OPT_BOOL('e', "edit", &edit_flag, N_("force edit of commit")),
OPT_CLEANUP(&cleanup_arg),
OPT_BOOL(0, "status", &include_status, N_("include status in commit message template")),
- { OPTION_STRING, 'S', "gpg-sign", &sign_commit, N_("key-id"),
+ { OPTION_STRING, 'S', "crypto-sign", &sign_commit, N_("key-id"),
+ N_("cryptographically sign commit"), PARSE_OPT_OPTARG, NULL, (intptr_t) "" },
+ { OPTION_STRING, 0, "gpg-sign", &sign_commit, N_("key-id"),
N_("GPG sign commit"), PARSE_OPT_OPTARG, NULL, (intptr_t) "" },
+
/* end commit message options */
OPT_GROUP(N_("Commit contents options")),
