Mehul Jain <mehul.jain2029@xxxxxxxxx> writes:
> In patch 2/3 and 3/3, there are many tests which requires a branch
> similar to that of "signed" branch, i.e. a branch with a commit having
> GPG signature. So previously in v2, I created two new branches,
> "test_sign" and "no_sign", which are identical to that of "signed"
> branch. And with these branches, I wrote the tests in patch 2/3
> and 3/3.
>
> As suggested by Eric [1], rather than creating new branches, I
> can take advantage of "signed" branch which already exists.
Yeah, I understand that part. But you do not _need_ to do the split
you do in 1/3 in order to reuse "signed".
The first 'log --graph --signature' test may fail, but it is not
like that the test without 1/3 removes the "signed" branch when
"log" command or the signature tests of its output fail, so "I
didn't want the later tests to depend on the first test being
successful" does not quite justify the split. If "commit -S" step,
which 1/3 splits into the earlier one of the two, fails, then you
won't have a signed commit to use in the later tests, even though
you have "signed" branch. The split of the tests done by 1/3 does
not make the tests more robust. If the commands in the original
in the part of the first test in the original that you keep in the
first half with 1/3 fail, subsequent tests will be affected with or
without 1/3.
If 1/3 justifies the change a bit differently, it would become a
good one.
In 2/3 and 3/3, we will use the same 'signed' branch that the
first test for 'log --graph --show-signature' uses. This branch
is currently created in that 'log --graph --show-signature' test
itself.
Split the set-up part into a test of its own, and make the
existing first test into a separate one that only inspects the
history on the 'signed' branch. That way, it would become
clearer that later tests added by 2/3 and 3/3 reuse the 'signed'
branch in the same way this 'log --graph --show-signature' uses
that same branch.
Of course, you would need to keep GPG prerequisite for both halves
1/3 creates.
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