On 2024-04-17 08:33, Kristoffer Haugsbakk wrote:
It could be useful to Cc the author of that commit since it’s so
recent. Like an FYI.
Good point. Will do that in the v2.
On Wed, Apr 17, 2024, at 05:32, Dragan Simic wrote:
Fix a bug that allows --rfc and -k options to be specified together
when
executing "git format-patch". This bug was introduced back in the
commit
e0d7db7423a9 ("format-patch: --rfc honors what --subject-prefix
sets"),
about eight months ago, but it has remained undetected so far,
presumably
because of no associated test coverage.
I don’t think speculating on why the bug is still there improves the
commit message.
Perhaps you're right, but perhaps I'm also right with that speculation.
:)
This paragraph could perhaps be rewritten to
“ Fix a bug from e0d7db7423a (format-patch: --rfc honors what
--subject-prefix sets, 2023-08-30) that allows --rfc and -k options
to be specified together when executing "git format-patch".
The extra sentence in the original doesn’t really explain anything more
about the commit. Except the “eight months ago”, but here I’ve used the
“reference” style (not the Linux-style) which contains the date.
I'm fine with that. Though, I just tried to explain it all in prose,
which may actually be helpful to the people going through the repository
history later.
Add a new test to the t4014 that covers the mutual exclusivity of the
--rfc
and -k command-line options for "git format-patch", for future
coverage.
I.e. add a regression test. Pretty standard.
Yes, pretty standard, but again, it obviously wasn't that standard
to the other authors, who missed to include such a test.
Signed-off-by: Dragan Simic <dsimic@xxxxxxxxxxx>
---
builtin/log.c | 5 ++++-
t/t4014-format-patch.sh | 4 ++++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/builtin/log.c b/builtin/log.c
index c0a8bb95e983..e5a238f1cf2c 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -2050,8 +2050,11 @@ int cmd_format_patch(int argc, const char
**argv, const char *prefix)
if (cover_from_description_arg)
cover_from_description_mode =
parse_cover_from_description(cover_from_description_arg);
- if (rfc)
+ /* Also mark the subject prefix as modified, for later checks */
I think the code speaks for itself in this case.
Alright, two votes so far, so this comments gets deleted in the v2. :)
I'm perfectly fine with that.
+ if (rfc) {
strbuf_insertstr(&sprefix, 0, "RFC ");
+ subject_prefix = 1;
+ }
if (reroll_count) {
strbuf_addf(&sprefix, " v%s", reroll_count);
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index e37a1411ee24..e22c4ac34e6e 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -1397,6 +1397,10 @@ test_expect_success '--rfc is argument order
independent' '
test_cmp expect actual
'
+test_expect_success '--rfc and -k cannot be used together' '
+ test_must_fail git format-patch -1 --stdout --rfc -k >patch
I don’t understand why you redirect to `patch` if you only check the
exit code. (I don’t expect any stdout since it will fail.)
You're right, but who knows what might actually happen in the
future, i.e. while someone in the future makes some changes to
the code and runs this test? It's better to stay on the safe
side and prevent some output from appearing somewhere.
Although it would be nice with a text comparison or grep on the stderr
output to make sure that the command died for the expected reason. But
I
haven’t read the associated code.
Yes, it would be nice, and the same thoughts actually already
crossed my mind while working on this patch, but there are already
more similar tests that don't validate such stderr outputs. Thus,
perhaps it would be better to improve such tests, including this one,
in a separate follow-up series.
+'
+
test_expect_success '--from=ident notices bogus ident' '
test_must_fail git format-patch -1 --stdout --from=foo >patch
'
