Re: [PATCH v2 1/9] cherry-pick, revert: add the --gpg-sign option
brian m. carlson sand...@crustytoothpaste.net writes:
+-S[keyid]::
+--gpg-sign[=keyid]::
+ GPG-sign commits.
+
Does this accept --no-gpg-sign? If not, shouldn't it?
diff --git a/sequencer.c b/sequencer.c
index 90cac7b..bde5f04 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -392,11 +392,18 @@ static int run_git_commit(const char *defmsg, struct
replay_opts *opts,
{
struct argv_array array;
int rc;
+ char *gpg_sign;
argv_array_init(array);
argv_array_push(array, commit);
argv_array_push(array, -n);
+ if (opts-gpg_sign) {
+ gpg_sign = xmalloc(3 + strlen(opts-gpg_sign));
+ sprintf(gpg_sign, -S%s, opts-gpg_sign);
+ argv_array_push(array, gpg_sign);
+ free(gpg_sign);
+ }
Here you would need to invent a new way to propagate --no-gpg-sign
to subsequent invocations, I think.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/9] cherry-pick, revert: add the --gpg-sign option
On Fri, Jan 24, 2014 at 01:00:06PM -0800, Junio C Hamano wrote:
brian m. carlson sand...@crustytoothpaste.net writes:
+-S[keyid]::
+--gpg-sign[=keyid]::
+ GPG-sign commits.
+
Does this accept --no-gpg-sign? If not, shouldn't it?
It does not. I took Nicolas's patches from the list and applied them to
master, so nothing from next is there, including the commit.gpgsign
stuff.
Would you prefer I rebased them on next instead?
diff --git a/sequencer.c b/sequencer.c
index 90cac7b..bde5f04 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -392,11 +392,18 @@ static int run_git_commit(const char *defmsg, struct
replay_opts *opts,
{
struct argv_array array;
int rc;
+ char *gpg_sign;
argv_array_init(array);
argv_array_push(array, commit);
argv_array_push(array, -n);
+ if (opts-gpg_sign) {
+ gpg_sign = xmalloc(3 + strlen(opts-gpg_sign));
+ sprintf(gpg_sign, -S%s, opts-gpg_sign);
+ argv_array_push(array, gpg_sign);
+ free(gpg_sign);
+ }
Here you would need to invent a new way to propagate --no-gpg-sign
to subsequent invocations, I think.
Probably. It wouldn't be too terribly difficult.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
signature.asc
Description: Digital signature
Re: [PATCH v2 1/9] cherry-pick, revert: add the --gpg-sign option
brian m. carlson sand...@crustytoothpaste.net writes: On Fri, Jan 24, 2014 at 01:00:06PM -0800, Junio C Hamano wrote: brian m. carlson sand...@crustytoothpaste.net writes: +-S[keyid]:: +--gpg-sign[=keyid]:: + GPG-sign commits. + Does this accept --no-gpg-sign? If not, shouldn't it? It does not. I took Nicolas's patches from the list and applied them to master, so nothing from next is there, including the commit.gpgsign stuff. Would you prefer I rebased them on next instead? Not really. It is debatable if it should mean that the user wants to sign commits that are created by running other commands like am and stash when he sets commit.gpgsign to true, but even if the answer to that question were true, the configuration must be overridable with e.g. git stash --no-gpg-sign, explicitly from the command line. Until that happens, the series with 2af2ef3c (Add the commit.gpgsign option to sign all commits, 2013-11-05) cannot be merged to 'master'. A series that lets you specify positives from the command line without any sticky configuration variable, i.e. these patches, do not have to wait for that to happen. So this series should come first and then the commit.gpgsign ones can be rebased on top of this series, I would think. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
