* [PATCH v3 1/3] t3435: use `test_config` instead of `git config` @ 2020-10-13 21:30 Samuel Čavoj 2020-10-13 21:30 ` [PATCH v3 2/3] sequencer: fix gpg option passed to merge subcommand Samuel Čavoj ` (2 more replies) 0 siblings, 3 replies; 9+ messages in thread From: Samuel Čavoj @ 2020-10-13 21:30 UTC (permalink / raw) To: git, Junio C Hamano; +Cc: Phillip Wood, Samuel Čavoj Replace usages of `git config` with `test_config` in t3435 to prevent side-effects between tests. Signed-off-by: Samuel Čavoj <samuel@cavoj.net> --- changed v2 -> v3: - added this patch --- t/t3435-rebase-gpg-sign.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/t/t3435-rebase-gpg-sign.sh b/t/t3435-rebase-gpg-sign.sh index b47c59c190..696cb6b6a4 100755 --- a/t/t3435-rebase-gpg-sign.sh +++ b/t/t3435-rebase-gpg-sign.sh @@ -27,7 +27,7 @@ test_rebase_gpg_sign () { shift test_expect_success "rebase $* with commit.gpgsign=$conf $will sign commit" " git reset two && - git config commit.gpgsign $conf && + test_config commit.gpgsign $conf && set_fake_editor && FAKE_LINES='r 1 p 2' git rebase --force-rebase --root $* && $must_fail git verify-commit HEAD^ && @@ -63,7 +63,7 @@ test_rebase_gpg_sign false -i --no-gpg-sign --gpg-sign test_expect_failure 'rebase -p --no-gpg-sign override commit.gpgsign' ' git reset --hard merged && - git config commit.gpgsign true && + test_config commit.gpgsign true && git rebase -p --no-gpg-sign --onto=one fork-point master && test_must_fail git verify-commit HEAD ' -- 2.28.0 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* [PATCH v3 2/3] sequencer: fix gpg option passed to merge subcommand 2020-10-13 21:30 [PATCH v3 1/3] t3435: use `test_config` instead of `git config` Samuel Čavoj @ 2020-10-13 21:30 ` Samuel Čavoj 2020-10-15 16:47 ` Junio C Hamano 2020-10-13 21:30 ` [PATCH v3 3/3] sequencer: pass explicit --no-gpg-sign to merge Samuel Čavoj 2020-10-15 16:43 ` [PATCH v3 1/3] t3435: use `test_config` instead of `git config` Junio C Hamano 2 siblings, 1 reply; 9+ messages in thread From: Samuel Čavoj @ 2020-10-13 21:30 UTC (permalink / raw) To: git, Junio C Hamano; +Cc: Phillip Wood, Samuel Čavoj When performing a rebase with --rebase-merges using either a custom strategy specified with -s or an octopus merge, and at the same time having gpgsign enabled (either rebase -S or config commit.gpgsign), the operation would fail on making the merge commit. Instead of "-S%s" with the key id substituted, only the bare key id would get passed to the underlying merge command, which tried to interpret it as a ref. Fix the issue and add test cases as suggested by Johannes Schindelin. Signed-off-by: Samuel Čavoj <samuel@cavoj.net> --- changed v2 -> v3: - first test is now okay, thanks to patch 1/3 - added another test for config commit.gpgsign --- sequencer.c | 2 +- t/t3435-rebase-gpg-sign.sh | 13 +++++++++++++ 2 files changed, 14 insertions(+), 1 deletion(-) diff --git a/sequencer.c b/sequencer.c index 00acb12496..88ccff4838 100644 --- a/sequencer.c +++ b/sequencer.c @@ -3677,7 +3677,7 @@ static int do_merge(struct repository *r, strvec_push(&cmd.args, "-F"); strvec_push(&cmd.args, git_path_merge_msg(r)); if (opts->gpg_sign) - strvec_push(&cmd.args, opts->gpg_sign); + strvec_pushf(&cmd.args, "-S%s", opts->gpg_sign); /* Add the tips to be merged */ for (j = to_merge; j; j = j->next) diff --git a/t/t3435-rebase-gpg-sign.sh b/t/t3435-rebase-gpg-sign.sh index 696cb6b6a4..9d2faffa03 100755 --- a/t/t3435-rebase-gpg-sign.sh +++ b/t/t3435-rebase-gpg-sign.sh @@ -68,4 +68,17 @@ test_expect_failure 'rebase -p --no-gpg-sign override commit.gpgsign' ' test_must_fail git verify-commit HEAD ' +test_expect_success 'rebase -r, GPG --gpg-sign and merge strategies' ' + git reset --hard merged && + git rebase -fr --gpg-sign -s resolve --root && + git verify-commit HEAD +' + +test_expect_success 'rebase -r, GPG config and merge strategies' ' + git reset --hard merged && + test_config commit.gpgsign true && + git rebase -fr -s resolve --root && + git verify-commit HEAD +' + test_done -- 2.28.0 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH v3 2/3] sequencer: fix gpg option passed to merge subcommand 2020-10-13 21:30 ` [PATCH v3 2/3] sequencer: fix gpg option passed to merge subcommand Samuel Čavoj @ 2020-10-15 16:47 ` Junio C Hamano 0 siblings, 0 replies; 9+ messages in thread From: Junio C Hamano @ 2020-10-15 16:47 UTC (permalink / raw) To: Samuel Čavoj; +Cc: git, Phillip Wood Samuel Čavoj <samuel@cavoj.net> writes: > diff --git a/sequencer.c b/sequencer.c > index 00acb12496..88ccff4838 100644 > --- a/sequencer.c > +++ b/sequencer.c > @@ -3677,7 +3677,7 @@ static int do_merge(struct repository *r, > strvec_push(&cmd.args, "-F"); > strvec_push(&cmd.args, git_path_merge_msg(r)); > if (opts->gpg_sign) > - strvec_push(&cmd.args, opts->gpg_sign); > + strvec_pushf(&cmd.args, "-S%s", opts->gpg_sign); Good. And later you'd add "else" to explicitly turn it off, I presume? > diff --git a/t/t3435-rebase-gpg-sign.sh b/t/t3435-rebase-gpg-sign.sh > index 696cb6b6a4..9d2faffa03 100755 > --- a/t/t3435-rebase-gpg-sign.sh > +++ b/t/t3435-rebase-gpg-sign.sh > @@ -68,4 +68,17 @@ test_expect_failure 'rebase -p --no-gpg-sign override commit.gpgsign' ' > test_must_fail git verify-commit HEAD > ' > > +test_expect_success 'rebase -r, GPG --gpg-sign and merge strategies' ' > + git reset --hard merged && Insert test_unconfig commit.gpgsign && here. That would make it explicit that we are checking the base case where only the command line option is given. > + git rebase -fr --gpg-sign -s resolve --root && > + git verify-commit HEAD > +' > + > +test_expect_success 'rebase -r, GPG config and merge strategies' ' > + git reset --hard merged && > + test_config commit.gpgsign true && Use "git config" for consistency. > + git rebase -fr -s resolve --root && > + git verify-commit HEAD > +' > + We'd want another one, which is to give --gpg-sign from the command line when this is in effect: git config commit.gpgsign false i.e. not "test_unconfig" that removes the configuration, but explicitly configured not to sign Thanks. ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH v3 3/3] sequencer: pass explicit --no-gpg-sign to merge 2020-10-13 21:30 [PATCH v3 1/3] t3435: use `test_config` instead of `git config` Samuel Čavoj 2020-10-13 21:30 ` [PATCH v3 2/3] sequencer: fix gpg option passed to merge subcommand Samuel Čavoj @ 2020-10-13 21:30 ` Samuel Čavoj 2020-10-15 17:02 ` Junio C Hamano 2020-10-15 16:43 ` [PATCH v3 1/3] t3435: use `test_config` instead of `git config` Junio C Hamano 2 siblings, 1 reply; 9+ messages in thread From: Samuel Čavoj @ 2020-10-13 21:30 UTC (permalink / raw) To: git, Junio C Hamano; +Cc: Phillip Wood, Samuel Čavoj The merge subcommand launched for merges with non-default strategy would use its own default behaviour to decide how to sign commits, regardless of what opts->gpg_sign was set to. For example the --no-gpg-sign flag given to rebase explicitly would get ignored, if commit.gpgsign was set to true. Fix the issue and add a test case excercising this behaviour. Signed-off-by: Samuel Čavoj <samuel@cavoj.net> --- v2 -> v3: - added test case --- sequencer.c | 2 ++ t/t3435-rebase-gpg-sign.sh | 7 +++++++ 2 files changed, 9 insertions(+) diff --git a/sequencer.c b/sequencer.c index 88ccff4838..043d606829 100644 --- a/sequencer.c +++ b/sequencer.c @@ -3678,6 +3678,8 @@ static int do_merge(struct repository *r, strvec_push(&cmd.args, git_path_merge_msg(r)); if (opts->gpg_sign) strvec_pushf(&cmd.args, "-S%s", opts->gpg_sign); + else + strvec_push(&cmd.args, "--no-gpg-sign"); /* Add the tips to be merged */ for (j = to_merge; j; j = j->next) diff --git a/t/t3435-rebase-gpg-sign.sh b/t/t3435-rebase-gpg-sign.sh index 9d2faffa03..773c2a1d72 100755 --- a/t/t3435-rebase-gpg-sign.sh +++ b/t/t3435-rebase-gpg-sign.sh @@ -81,4 +81,11 @@ test_expect_success 'rebase -r, GPG config and merge strategies' ' git verify-commit HEAD ' +test_expect_success 'rebase -r, --no-gpg-sign and merge strategies' ' + git reset --hard merged && + test_config commit.gpgsign true && + git rebase -fr --no-gpg-sign -s resolve --root && + test_must_fail git verify-commit HEAD +' + test_done -- 2.28.0 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH v3 3/3] sequencer: pass explicit --no-gpg-sign to merge 2020-10-13 21:30 ` [PATCH v3 3/3] sequencer: pass explicit --no-gpg-sign to merge Samuel Čavoj @ 2020-10-15 17:02 ` Junio C Hamano 2020-10-17 22:02 ` Samuel Čavoj 0 siblings, 1 reply; 9+ messages in thread From: Junio C Hamano @ 2020-10-15 17:02 UTC (permalink / raw) To: Samuel Čavoj; +Cc: git, Phillip Wood Samuel Čavoj <samuel@cavoj.net> writes: > The merge subcommand launched for merges with non-default strategy would > use its own default behaviour to decide how to sign commits, regardless > of what opts->gpg_sign was set to. For example the --no-gpg-sign flag > given to rebase explicitly would get ignored, if commit.gpgsign was set > to true. > > Fix the issue and add a test case excercising this behaviour. > > Signed-off-by: Samuel Čavoj <samuel@cavoj.net> > --- > v2 -> v3: > - added test case > --- > sequencer.c | 2 ++ > t/t3435-rebase-gpg-sign.sh | 7 +++++++ > 2 files changed, 9 insertions(+) > > diff --git a/sequencer.c b/sequencer.c > index 88ccff4838..043d606829 100644 > --- a/sequencer.c > +++ b/sequencer.c > @@ -3678,6 +3678,8 @@ static int do_merge(struct repository *r, > strvec_push(&cmd.args, git_path_merge_msg(r)); > if (opts->gpg_sign) > strvec_pushf(&cmd.args, "-S%s", opts->gpg_sign); > + else > + strvec_push(&cmd.args, "--no-gpg-sign"); Makes sense, I guess. As long as opts->gpg_sign reflects not just the command line but also the configuration. Otherwise, an invocation of "git rebase" with no gpg-sign related command line options would say "ah, opts->gpg_sign is false, we must have been told from the command line not to sign, so pass --no-gpg-sign here" and that is not correct. > diff --git a/t/t3435-rebase-gpg-sign.sh b/t/t3435-rebase-gpg-sign.sh > index 9d2faffa03..773c2a1d72 100755 > --- a/t/t3435-rebase-gpg-sign.sh > +++ b/t/t3435-rebase-gpg-sign.sh > @@ -81,4 +81,11 @@ test_expect_success 'rebase -r, GPG config and merge strategies' ' > git verify-commit HEAD > ' > > +test_expect_success 'rebase -r, --no-gpg-sign and merge strategies' ' > + git reset --hard merged && > + test_config commit.gpgsign true && > + git rebase -fr --no-gpg-sign -s resolve --root && > + test_must_fail git verify-commit HEAD > +' I think that before this patch, we've tested the "no command line option, but configuration tells us to sign" combination already to make sure the result is signed, so this new test is sufficient. I briefly wondered if "test_must_fail git verify-commit" sufficient to make sure that the rebased commits are not signed (i.e. verify may fail for reasons other than the commit lacks signature, like the commit is signed but with a wrong key, etc.), but I think it is OK at least for now. Others might have clever ideas to cleanly and cheaply reject other kinds of failures, in which case we may want to adopt such a solution. Now that we know that the root cause of the bug you fixed was because rebase rebase with the default merge strategy for two-head merges use separate codepaths from and all other rebases, I wonder if it is prudent to also test the same cases this series adds without giving "-s resolve". That would exercise the other codepath that handles the default merge strategy for two-head merges. Yes, we know that other codepath has been working even before this fix, but tests are not about showing off what we fixed, but are about making sure similar breakage won't be introduced by mistake in the future. Thanks. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v3 3/3] sequencer: pass explicit --no-gpg-sign to merge 2020-10-15 17:02 ` Junio C Hamano @ 2020-10-17 22:02 ` Samuel Čavoj 2020-10-17 22:34 ` Junio C Hamano 0 siblings, 1 reply; 9+ messages in thread From: Samuel Čavoj @ 2020-10-17 22:02 UTC (permalink / raw) To: Junio C Hamano; +Cc: git, Phillip Wood Hi Junio, On 15.10.2020 10:02, Junio C Hamano wrote: > Samuel Čavoj <samuel@cavoj.net> writes: > > > The merge subcommand launched for merges with non-default strategy would > > use its own default behaviour to decide how to sign commits, regardless > > of what opts->gpg_sign was set to. For example the --no-gpg-sign flag > > given to rebase explicitly would get ignored, if commit.gpgsign was set > > to true. > > > > Fix the issue and add a test case excercising this behaviour. > > > > Signed-off-by: Samuel Čavoj <samuel@cavoj.net> > > --- > > v2 -> v3: > > - added test case > > --- > > sequencer.c | 2 ++ > > t/t3435-rebase-gpg-sign.sh | 7 +++++++ > > 2 files changed, 9 insertions(+) > > > > diff --git a/sequencer.c b/sequencer.c > > index 88ccff4838..043d606829 100644 > > --- a/sequencer.c > > +++ b/sequencer.c > > @@ -3678,6 +3678,8 @@ static int do_merge(struct repository *r, > > strvec_push(&cmd.args, git_path_merge_msg(r)); > > if (opts->gpg_sign) > > strvec_pushf(&cmd.args, "-S%s", opts->gpg_sign); > > + else > > + strvec_push(&cmd.args, "--no-gpg-sign"); > > Makes sense, I guess. As long as opts->gpg_sign reflects not just > the command line but also the configuration. Otherwise, an > invocation of "git rebase" with no gpg-sign related command line > options would say "ah, opts->gpg_sign is false, we must have been > told from the command line not to sign, so pass --no-gpg-sign here" > and that is not correct. > > > diff --git a/t/t3435-rebase-gpg-sign.sh b/t/t3435-rebase-gpg-sign.sh > > index 9d2faffa03..773c2a1d72 100755 > > --- a/t/t3435-rebase-gpg-sign.sh > > +++ b/t/t3435-rebase-gpg-sign.sh > > @@ -81,4 +81,11 @@ test_expect_success 'rebase -r, GPG config and merge strategies' ' > > git verify-commit HEAD > > ' > > > > +test_expect_success 'rebase -r, --no-gpg-sign and merge strategies' ' > > + git reset --hard merged && > > + test_config commit.gpgsign true && > > + git rebase -fr --no-gpg-sign -s resolve --root && > > + test_must_fail git verify-commit HEAD > > +' > > I think that before this patch, we've tested the "no command line > option, but configuration tells us to sign" combination already to > make sure the result is signed, so this new test is sufficient. > > I briefly wondered if "test_must_fail git verify-commit" sufficient > to make sure that the rebased commits are not signed (i.e. verify > may fail for reasons other than the commit lacks signature, like the > commit is signed but with a wrong key, etc.), but I think it is OK > at least for now. Others might have clever ideas to cleanly and > cheaply reject other kinds of failures, in which case we may want to > adopt such a solution. > > Now that we know that the root cause of the bug you fixed was > because rebase rebase with the default merge strategy for two-head > merges use separate codepaths from and all other rebases, I wonder > if it is prudent to also test the same cases this series adds > without giving "-s resolve". That would exercise the other codepath I will leave that for someone else to tackle eventually. > that handles the default merge strategy for two-head merges. Yes, > we know that other codepath has been working even before this fix, > but tests are not about showing off what we fixed, but are about > making sure similar breakage won't be introduced by mistake in the > future. > > Thanks. As the number of very similar test is slowly growing, do you think it is worth copying (or making more generic) the test_rebase_gpg_sign for this situation as well? We currently have 4 almost identical tests (counting the new one you suggested for v4). Just a thought, as it is simpler to just add it at this point. Thanks for the feedback. Regards, Samuel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v3 3/3] sequencer: pass explicit --no-gpg-sign to merge 2020-10-17 22:02 ` Samuel Čavoj @ 2020-10-17 22:34 ` Junio C Hamano 2020-10-17 23:16 ` Samuel Čavoj 0 siblings, 1 reply; 9+ messages in thread From: Junio C Hamano @ 2020-10-17 22:34 UTC (permalink / raw) To: Samuel Čavoj; +Cc: git, Phillip Wood Samuel Čavoj <samuel@cavoj.net> writes: >> Now that we know that the root cause of the bug you fixed was >> because rebase rebase with the default merge strategy for two-head >> merges use separate codepaths from and all other rebases, I wonder >> if it is prudent to also test the same cases this series adds >> without giving "-s resolve". That would exercise the other codepath > > I will leave that for someone else to tackle eventually. We know that other codepath has been working even before this fix, but tests are not about showing off what we fixed, but are about making sure similar breakage won't be introduced by mistake in the future. Leaving it "for someone", when we know what the problem is and how to solve it, is asking for the "evantually" not materialize forever. > As the number of very similar test is slowly growing, do you think it is > worth copying (or making more generic) the test_rebase_gpg_sign for this > situation as well? We currently have 4 almost identical tests (counting > the new one you suggested for v4). Just a thought, as it is simpler to > just add it at this point. Thanks for the feedback. That is a tough question. Often, a generic test helper makes it too easy to do a full matrix of tests and encourages us to overdo it, which we probably would want to avoid. I think what I've suggested so far is a bare minimum combination for code coverage. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v3 3/3] sequencer: pass explicit --no-gpg-sign to merge 2020-10-17 22:34 ` Junio C Hamano @ 2020-10-17 23:16 ` Samuel Čavoj 0 siblings, 0 replies; 9+ messages in thread From: Samuel Čavoj @ 2020-10-17 23:16 UTC (permalink / raw) To: Junio C Hamano; +Cc: git, Phillip Wood Hi, On 17.10.2020 15:34, Junio C Hamano wrote: > Samuel Čavoj <samuel@cavoj.net> writes: > > >> Now that we know that the root cause of the bug you fixed was > >> because rebase rebase with the default merge strategy for two-head > >> merges use separate codepaths from and all other rebases, I wonder > >> if it is prudent to also test the same cases this series adds > >> without giving "-s resolve". That would exercise the other codepath > > > > I will leave that for someone else to tackle eventually. > > We know that other codepath has been working even before this fix, > but tests are not about showing off what we fixed, but are about > making sure similar breakage won't be introduced by mistake in the > future. Leaving it "for someone", when we know what the problem is > and how to solve it, is asking for the "evantually" not materialize > forever. I agree with that, don't take me wrong, but in general, people have other things to do, than implement test cases only marginally related to the inital patch they submitted. Anyway, as it didn't take long in this case, I added them as patch 3/3 in v4. > > > As the number of very similar test is slowly growing, do you think it is > > worth copying (or making more generic) the test_rebase_gpg_sign for this > > situation as well? We currently have 4 almost identical tests (counting > > the new one you suggested for v4). Just a thought, as it is simpler to > > just add it at this point. Thanks for the feedback. > > That is a tough question. Often, a generic test helper makes it too > easy to do a full matrix of tests and encourages us to overdo it, > which we probably would want to avoid. I think what I've suggested > so far is a bare minimum combination for code coverage. > Alright, I will leave them as is. Regards, Samuel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v3 1/3] t3435: use `test_config` instead of `git config` 2020-10-13 21:30 [PATCH v3 1/3] t3435: use `test_config` instead of `git config` Samuel Čavoj 2020-10-13 21:30 ` [PATCH v3 2/3] sequencer: fix gpg option passed to merge subcommand Samuel Čavoj 2020-10-13 21:30 ` [PATCH v3 3/3] sequencer: pass explicit --no-gpg-sign to merge Samuel Čavoj @ 2020-10-15 16:43 ` Junio C Hamano 2 siblings, 0 replies; 9+ messages in thread From: Junio C Hamano @ 2020-10-15 16:43 UTC (permalink / raw) To: Samuel Čavoj; +Cc: git, Phillip Wood Samuel Čavoj <samuel@cavoj.net> writes: > Replace usages of `git config` with `test_config` in t3435 to prevent > side-effects between tests. > > Signed-off-by: Samuel Čavoj <samuel@cavoj.net> > --- > changed v2 -> v3: > - added this patch > --- > t/t3435-rebase-gpg-sign.sh | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) As I already said, I think this is not needed. The way the existing tests protect themselves from what previously happened is to explicitly set up _their_ expectation in them before running the part that is affected by the configuration setting, which is an approach that is easy to read and understand because it is explicit in what these tests care about. > diff --git a/t/t3435-rebase-gpg-sign.sh b/t/t3435-rebase-gpg-sign.sh > index b47c59c190..696cb6b6a4 100755 > --- a/t/t3435-rebase-gpg-sign.sh > +++ b/t/t3435-rebase-gpg-sign.sh > @@ -27,7 +27,7 @@ test_rebase_gpg_sign () { > shift > test_expect_success "rebase $* with commit.gpgsign=$conf $will sign commit" " > git reset two && > - git config commit.gpgsign $conf && > + test_config commit.gpgsign $conf && > set_fake_editor && > FAKE_LINES='r 1 p 2' git rebase --force-rebase --root $* && > $must_fail git verify-commit HEAD^ && These are the first three uses of this test helper. test_rebase_gpg_sign ! false test_rebase_gpg_sign true test_rebase_gpg_sign ! true --no-gpg-sign Examine what this patch does to the second test that is run by the second invocation of test_rebase_gpg_sign, for example. Before this patch, "git config" that was done by the first test is left and commit.gpgsign was set to 'false' when the second test started. With this patch, it is removed by the clean-up action set by test_config, so the second test starts without the configuration. But this patch does *not* affect correctness of the second invocation. Why? Because the way these tests protect themselves is NOT based on the "I muck with configuration, so I'll clean them up for the next person" attitude which is made easy to do with test_config ANYWAY. The correctness of the second test still relies on the fact that it itself tweaks the variable it cares about to the state it wants it to be. So in this particular test script, where all test pieces are about checking their behaviour on different setting of commit.gpgsign, use of test_config does not buy us anything other than extra clean-up after each test that is unnecessary. Where test_config shines is when only a few (or a single) test cares about different setting of a variable, and all later tests want to test the behaviour under the default setting. Among 47 tests, the second and 42nd tests may want to test with commit.gpgsign set to true, while the remainder may want to test without the variable at all. In such a case, it is easier to declare that the normal state in that test script is not to have the configuration, and use test_config in these selected tests to tentatively set it and remove it after the tests are done. But that rationale does not apply to this script. It seems that each test piece wants to be in control of and be tested under specific setting of the variable. > @@ -63,7 +63,7 @@ test_rebase_gpg_sign false -i --no-gpg-sign --gpg-sign > > test_expect_failure 'rebase -p --no-gpg-sign override commit.gpgsign' ' > git reset --hard merged && > - git config commit.gpgsign true && > + test_config commit.gpgsign true && > git rebase -p --no-gpg-sign --onto=one fork-point master && > test_must_fail git verify-commit HEAD > ' ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2020-10-17 23:16 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-10-13 21:30 [PATCH v3 1/3] t3435: use `test_config` instead of `git config` Samuel Čavoj 2020-10-13 21:30 ` [PATCH v3 2/3] sequencer: fix gpg option passed to merge subcommand Samuel Čavoj 2020-10-15 16:47 ` Junio C Hamano 2020-10-13 21:30 ` [PATCH v3 3/3] sequencer: pass explicit --no-gpg-sign to merge Samuel Čavoj 2020-10-15 17:02 ` Junio C Hamano 2020-10-17 22:02 ` Samuel Čavoj 2020-10-17 22:34 ` Junio C Hamano 2020-10-17 23:16 ` Samuel Čavoj 2020-10-15 16:43 ` [PATCH v3 1/3] t3435: use `test_config` instead of `git config` Junio C Hamano
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).