Re: [PATCH 2/4] format-patch: fix a bug in option exclusivity and add a test to t4014

[Dragan Simic <dsimic@manjaro.org>]

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.