| Message ID | c975f961779b4a7b10c0743b4b8b3ad8c89cb617.1713324598.git.dsimic@manjaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | format-patch: fix an option coexistence bug and add new --resend option | expand |
On Tue, Apr 16, 2024 at 11:33 PM Dragan Simic <dsimic@manjaro.org> wrote: > format-patch: fix a bug in option exclusivity and add a test to t4014 Reviewers assume that a conscientious patch author will add tests when appropriate, so stating that you did so is unnecessary. Thus it's safe to omit "and add a test to t4014" without negatively impacting comprehension of the subject. format-patch: ensure --rfc and -k are mutually exclusive > 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. Everything starting at "...about eight months" through the end of the paragraph could be easily dropped. Reviewers understand implicitly that the bug went undiscovered due to lack of test coverage. > 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. Similarly, no need for this paragraph. As a conscientious patch author, reviewers assume that you added the test, so this paragraph adds no information. Also, the body of the patch provides this information clearly without it having to be stated here. > Signed-off-by: Dragan Simic <dsimic@manjaro.org> > --- > diff --git 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 (rfc) > + /* Also mark the subject prefix as modified, for later checks */ > + if (rfc) { > strbuf_insertstr(&sprefix, 0, "RFC "); > + subject_prefix = 1; > + } I'm not sure that this new comment (/* Also mark... */) adds any value beyond what the code itself already says. It may actually be confusing with its current placement. Had you placed it immediately above the `stubject_prefix = 1` line, it would have been more understandable, but still probably unnecessary since anyone studying this code is going to have to understand the purpose of `subject_prefix` anyhow. At any rate, I doubt that any of these review comments on their own is worth a reroll.
On Wed, Apr 17, 2024 at 05:32:42AM +0200, 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. > > 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. > > Signed-off-by: Dragan Simic <dsimic@manjaro.org> > --- > 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 */ > + if (rfc) { > strbuf_insertstr(&sprefix, 0, "RFC "); > + subject_prefix = 1; > + } As an alternative fix, can we drop `subject_prefix` and replace it with `sprefix.len` instead? It seems to merely be a proxy value for that anyway, and if we didn't have that variable then the bug would not have been possible to begin with. Patrick > 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 > +' > + > test_expect_success '--from=ident notices bogus ident' ' > test_must_fail git format-patch -1 --stdout --from=foo >patch > ' >
On 2024-04-17 08:15, Eric Sunshine wrote: > On Tue, Apr 16, 2024 at 11:33 PM Dragan Simic <dsimic@manjaro.org> > wrote: >> format-patch: fix a bug in option exclusivity and add a test to t4014 > > Reviewers assume that a conscientious patch author will add tests when > appropriate, so stating that you did so is unnecessary. Thus it's safe > to omit "and add a test to t4014" without negatively impacting > comprehension of the subject. > > format-patch: ensure --rfc and -k are mutually exclusive Makes sense, but the previous authors obviously weren't diligent enough to include such a test, which presumably made the fixed bug remain undetected for so long, so I wanted to put some emphasis on the addition of a test. >> 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. > > Everything starting at "...about eight months" through the end of the > paragraph could be easily dropped. Reviewers understand implicitly > that the bug went undiscovered due to lack of test coverage. I have no problems with dropping that part, but IMHO that's nitpicking. Also, dropping it would delete some of the context that people might find useful 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. > > Similarly, no need for this paragraph. As a conscientious patch > author, reviewers assume that you added the test, so this paragraph > adds no information. Also, the body of the patch provides this > information clearly without it having to be stated here. With all the respect, I think that having that paragraph is actually good, because explaining it clearly provides good context for the repository history and people reading it later. >> Signed-off-by: Dragan Simic <dsimic@manjaro.org> >> --- >> diff --git 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 (rfc) >> + /* Also mark the subject prefix as modified, for later checks >> */ >> + if (rfc) { >> strbuf_insertstr(&sprefix, 0, "RFC "); >> + subject_prefix = 1; >> + } > > I'm not sure that this new comment (/* Also mark... */) adds any value > beyond what the code itself already says. It may actually be confusing > with its current placement. Had you placed it immediately above the > `stubject_prefix = 1` line, it would have been more understandable, > but still probably unnecessary since anyone studying this code is > going to have to understand the purpose of `subject_prefix` anyhow. Setting such flags should actually be performed in a callback, but in this case creating a callback isn't warranted, IMHO. Thus, that comment tries to explain why a flag is set out of place. I have no objections against removing this comment, if you find it doing more harm than good. I didn't place it immediately above the relevant line because it also applies to the adjacent block for the --resend option, and I wanted to reduce the code churn that would result from placing it immediately before the relevant line, and moving it a couple of lines above just a couple of patches later. > At any rate, I doubt that any of these review comments on their own is > worth a reroll. Well, I need to split the series anyway, so the v2 is pretty much inevitable.
It could be useful to Cc the author of that commit since it’s so recent. Like an FYI. 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. 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. > 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. > > Signed-off-by: Dragan Simic <dsimic@manjaro.org> > --- > 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. > + 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.) 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. > +' > + > test_expect_success '--from=ident notices bogus ident' ' > test_must_fail git format-patch -1 --stdout --from=foo >patch > '
On Wed, Apr 17, 2024 at 2:34 AM Kristoffer Haugsbakk <code@khaugsbakk.name> wrote: > 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. > > 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. > > @@ -2050,8 +2050,11 @@ int cmd_format_patch(int argc, const char > > - if (rfc) > > + /* Also mark the subject prefix as modified, for later checks */ > > I think the code speaks for itself in this case. Apparently we're thinking along the same lines since we both said essentially the same things in our reviews. > > +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.) I had the same question but left it unwritten since I noticed that this new test is modelled after the test immediately following it in the script, and the existing test also redirects to "patch" unnecessarily. So, if it's done this way for consistency with existing tests, I don't mind letting it slide.
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@manjaro.org> >> --- >> 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 >> '
Hello Patrick, On 2024-04-17 08:27, Patrick Steinhardt wrote: > On Wed, Apr 17, 2024 at 05:32:42AM +0200, 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. >> >> 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. >> >> Signed-off-by: Dragan Simic <dsimic@manjaro.org> >> --- >> 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 */ >> + if (rfc) { >> strbuf_insertstr(&sprefix, 0, "RFC "); >> + subject_prefix = 1; >> + } > > As an alternative fix, can we drop `subject_prefix` and replace it with > `sprefix.len` instead? It seems to merely be a proxy value for that > anyway, and if we didn't have that variable then the bug would not have > been possible to begin with. Thanks for your feedback! I'll think about it, and I'll come back a bit later with an update. >> 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 >> +' >> + >> test_expect_success '--from=ident notices bogus ident' ' >> test_must_fail git format-patch -1 --stdout --from=foo >patch >> ' >>
On 2024-04-17 08:40, Eric Sunshine wrote: > On Wed, Apr 17, 2024 at 2:34 AM Kristoffer Haugsbakk > <code@khaugsbakk.name> wrote: >> 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. >> >> 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. >> > @@ -2050,8 +2050,11 @@ int cmd_format_patch(int argc, const char >> > - if (rfc) >> > + /* Also mark the subject prefix as modified, for later checks */ >> >> I think the code speaks for itself in this case. > > Apparently we're thinking along the same lines since we both said > essentially the same things in our reviews. Two votes, so the comments goes away. :) >> > +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.) > > I had the same question but left it unwritten since I noticed that > this new test is modelled after the test immediately following it in > the script, and the existing test also redirects to "patch" > unnecessarily. So, if it's done this way for consistency with existing > tests, I don't mind letting it slide. Yes, I also wasn't super happy with this new test, as I already noted in one of my replies, but improving this and the other similar tests is most probably something best left for a follow-up series.
On Wed, Apr 17, 2024, at 09:11, Dragan Simic wrote: >> I had the same question but left it unwritten since I noticed that >> this new test is modelled after the test immediately following it in >> the script, and the existing test also redirects to "patch" >> unnecessarily. So, if it's done this way for consistency with existing >> tests, I don't mind letting it slide. > > Yes, I also wasn't super happy with this new test, as I already noted > in one of my replies, but improving this and the other similar tests > is most probably something best left for a follow-up series. I don’t see the point in writing the test in mimic-neighbors way only to improve it shortly after. If the test can be written in a better way then the other tests can be improved later. Or now. I think I’ve seen other discussions were a less good pattern wasn’t accepted in new tests even though they were used in existing ones. The reviewer then pointed out that the other tests should be updated later. That’s just my opinion and recollection.
On 2024-04-17 13:38, Kristoffer Haugsbakk wrote: > On Wed, Apr 17, 2024, at 09:11, Dragan Simic wrote: >>> I had the same question but left it unwritten since I noticed that >>> this new test is modelled after the test immediately following it in >>> the script, and the existing test also redirects to "patch" >>> unnecessarily. So, if it's done this way for consistency with >>> existing >>> tests, I don't mind letting it slide. >> >> Yes, I also wasn't super happy with this new test, as I already noted >> in one of my replies, but improving this and the other similar tests >> is most probably something best left for a follow-up series. > > I don’t see the point in writing the test in mimic-neighbors way only > to > improve it shortly after. Well, the logic is quite simple: let me get this patch accepted, and we'll deal with the improvements later. Though, don't get me wrong, I'd always prefer to see things done the right way, but the time, just like the other resources, is limited. > If the test can be written in a better way then the other tests can be > improved later. Or now. I think I’ve seen other discussions were a less > good pattern wasn’t accepted in new tests even though they were used in > existing ones. The reviewer then pointed out that the other tests > should > be updated later. > > That’s just my opinion and recollection. I see, but this makes me wonder how often the other tests actually get improved later?
On 2024-04-17 08:33, Kristoffer Haugsbakk wrote: > On Wed, Apr 17, 2024, at 05:32, Dragan Simic wrote: >> 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.) > > 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. Actually, if you agree, we should check both the stdout and stderr -- the former for emptiness, and the latter for the expected error message. >> +' >> + >> test_expect_success '--from=ident notices bogus ident' ' >> test_must_fail git format-patch -1 --stdout --from=foo >patch >> '
Hello Patrick, On 2024-04-17 08:56, Dragan Simic wrote: > On 2024-04-17 08:27, Patrick Steinhardt wrote: >> On Wed, Apr 17, 2024 at 05:32:42AM +0200, 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. >>> >>> 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. >>> >>> Signed-off-by: Dragan Simic <dsimic@manjaro.org> >>> --- >>> 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 */ >>> + if (rfc) { >>> strbuf_insertstr(&sprefix, 0, "RFC "); >>> + subject_prefix = 1; >>> + } >> >> As an alternative fix, can we drop `subject_prefix` and replace it >> with >> `sprefix.len` instead? It seems to merely be a proxy value for that >> anyway, and if we didn't have that variable then the bug would not >> have >> been possible to begin with. > > Thanks for your feedback! > > I'll think about it, and I'll come back a bit later with an update. Unfortunately, we can't use sprefix.len instead, because it can still be zero even if the --subject-prefix option was present, more specifically if we receive --subject-prefix="" on the command line. The checks that use subject_prefix need to check if --subject-prefix was specified at all as an option, instead of checking if the actual subject prefix is of non-zero length. As you already noted, if sprefix.len was used instead of the separate subject_prefix variable, the '--rfc -k' bug wouldn't be possible, but the new '--subject-prefix="" -k' bug would be possible instead. >>> 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 >>> +' >>> + >>> test_expect_success '--from=ident notices bogus ident' ' >>> test_must_fail git format-patch -1 --stdout --from=foo >patch >>> '
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 */ + 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 +' + test_expect_success '--from=ident notices bogus ident' ' test_must_fail git format-patch -1 --stdout --from=foo >patch '
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. 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. Signed-off-by: Dragan Simic <dsimic@manjaro.org> --- builtin/log.c | 5 ++++- t/t4014-format-patch.sh | 4 ++++ 2 files changed, 8 insertions(+), 1 deletion(-)