[PATCH v3 1/3] t3435: use `test_config` instead of `git config`

[PATCH v3 1/3] t3435: use `test_config` instead of `git config`

[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

[PATCH v3 2/3] sequencer: fix gpg option passed to merge subcommand

[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

[PATCH v3 3/3] sequencer: pass explicit --no-gpg-sign to merge

[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

Re: [PATCH v3 1/3] t3435: use `test_config` instead of `git config`

[Junio C Hamano]

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
>  '

Re: [PATCH v3 2/3] sequencer: fix gpg option passed to merge subcommand

[Junio C Hamano]

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.

Re: [PATCH v3 3/3] sequencer: pass explicit --no-gpg-sign to merge

[Junio C Hamano]

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.

Re: [PATCH v3 3/3] sequencer: pass explicit --no-gpg-sign to merge

[Samuel Čavoj]

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

Re: [PATCH v3 3/3] sequencer: pass explicit --no-gpg-sign to merge

[Junio C Hamano]

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.

Re: [PATCH v3 3/3] sequencer: pass explicit --no-gpg-sign to merge

[Samuel Čavoj]

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