[PATCH 0/2] format-patch: handle range-diff on notes correctly for single patches

[PATCH 0/2] format-patch: handle range-diff on notes correctly for single patches

[kristofferhaugsbakk]

From: Kristoffer Haugsbakk <code@khaugsbakk.name>

git-format-patch(1) does not handle Git notes correctly in the
range-diff output for single-commit series.  It reverts to the
default behavior of git-range-diff(1), which is to act like git-log(1).

Fix that notes handling to always output the same notes (namespaces) in
the two positions:

• beneath the commit message; and
• in the range-diff.

Do that by (patch by patch):

1. Refactoring to use a new `ref_info` struct member
2. Using that in `log-tree.c`

§ Testing

I have (for once) tried to check for leaks by running the test suite
with this `config.mak`:

```
DEVELOPER=1
DEBUG=1
CC = ccache gcc
CFLAGS+=-O0
CFLAGS+=-ggdb3
USE_ASCIIDOCTOR=true
SANITIZE=leak,address
```

Kristoffer Haugsbakk (2):
  revision: add rdiff_other_arg to rev_info
  format-patch: handle range-diff on notes correctly for single patches

 builtin/log.c         |  7 +++----
 log-tree.c            |  3 ++-
 revision.h            |  1 +
 t/t3206-range-diff.sh | 16 +++++++++++++++-
 4 files changed, 21 insertions(+), 6 deletions(-)


base-commit: ca2559c1d630eb4f04cdee2328aaf1c768907a9e
-- 
2.51.0.270.gdb73cbc1bc1

[PATCH 1/2] revision: add rdiff_other_arg to rev_info

[kristofferhaugsbakk]

From: Kristoffer Haugsbakk <code@khaugsbakk.name>

git-format-patch(1) needs to pass `--[no-]notes` options on to the
range-diff subprocess in `range-diff.c`.  This is handled in `builtin/
log.c` by the local variable `other_arg` in the case of multiple
commits, but not in the single commit case where there is no cover
letter and the range-diff is on that single resulting patch; the
range-diff is then made in `log-tree.c`, whither `other_arg` has not
been propagated.

git-format-patch(1) is supposed to treat Git notes the same between
notes output beneath the commit message and the notes output for the
range-diff.  But this lack of notes handling in `log-tree.c` breaks
that expected behavior; range-diff notes handling for a single patch
acts like a normal git-range-diff(1) invocation with regards to notes.
You can, for example, end up with a patch where the note beneath the
commit message has the correct notes namespace, but the range-diff has
all the notes that are configured to be displayed by git-log(1).[1]

We need to fix this.  But first lay the groundwork by converting
`other_arg` to a struct member; next we can simply use that member
in `log-tree.c` without having to thread it from `builtin/log.c`.

No functional changes.

† 1: See the configuration variable `format.notes` for git-format-
     patch(1); c.f. `notes.displayRef` for git-log(1).  These two
     have nothing to do with each other.

Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
---

Notes (series):
    There is also `other_arg` in `builtin/range-diff.c` but `rev_info` does
    not seem to be involved.

 builtin/log.c | 7 +++----
 revision.h    | 1 +
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/builtin/log.c b/builtin/log.c
index 5f552d14c0f..56dd9fbc057 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -1400,13 +1400,12 @@ static void make_cover_letter(struct rev_info *rev, int use_separate_file,
 		 * can be added later if deemed desirable.
 		 */
 		struct diff_options opts;
-		struct strvec other_arg = STRVEC_INIT;
 		struct range_diff_options range_diff_opts = {
 			.creation_factor = rev->creation_factor,
 			.dual_color = 1,
 			.max_memory = RANGE_DIFF_MAX_MEMORY_DEFAULT,
 			.diffopt = &opts,
-			.other_arg = &other_arg
+			.other_arg = &rev->rdiff_other_arg
 		};
 
 		repo_diff_setup(the_repository, &opts);
@@ -1414,9 +1413,7 @@ static void make_cover_letter(struct rev_info *rev, int use_separate_file,
 		opts.use_color = rev->diffopt.use_color;
 		diff_setup_done(&opts);
 		fprintf_ln(rev->diffopt.file, "%s", rev->rdiff_title);
-		get_notes_args(&other_arg, rev);
 		show_range_diff(rev->rdiff1, rev->rdiff2, &range_diff_opts);
-		strvec_clear(&other_arg);
 	}
 }
 
@@ -2328,6 +2325,7 @@ int cmd_format_patch(int argc,
 		rev.rdiff_title = diff_title(&rdiff_title, reroll_count,
 					     _("Range-diff:"),
 					     _("Range-diff against v%d:"));
+		get_notes_args(&(rev.rdiff_other_arg), &rev);
 	}
 
 	/*
@@ -2487,6 +2485,7 @@ int cmd_format_patch(int argc,
 	rev.diffopt.no_free = 0;
 	release_revisions(&rev);
 	format_config_release(&cfg);
+	strvec_clear(&rev.rdiff_other_arg);
 	return 0;
 }
 
diff --git a/revision.h b/revision.h
index 21e288c5baa..26c18a0934b 100644
--- a/revision.h
+++ b/revision.h
@@ -334,6 +334,7 @@ struct rev_info {
 	/* range-diff */
 	const char *rdiff1;
 	const char *rdiff2;
+	struct strvec rdiff_other_arg;
 	int creation_factor;
 	const char *rdiff_title;
 
-- 
2.51.0.270.gdb73cbc1bc1

Re: [PATCH 1/2] revision: add rdiff_other_arg to rev_info

[Junio C Hamano]

kristofferhaugsbakk@fastmail.com writes:

> git-format-patch(1) is supposed to treat Git notes the same between
> notes output beneath the commit message and the notes output for the
> range-diff.

Is this an opinion, or are there things that existing pieces of code
already do to achieve such a behaviour already?

> diff --git a/revision.h b/revision.h
> index 21e288c5baa..26c18a0934b 100644
> --- a/revision.h
> +++ b/revision.h
> @@ -334,6 +334,7 @@ struct rev_info {
>  	/* range-diff */
>  	const char *rdiff1;
>  	const char *rdiff2;
> +	struct strvec rdiff_other_arg;
>  	int creation_factor;
>  	const char *rdiff_title;

When embedding a struct A in a struct B, we should always make sure
that initialization macro/function for struct B is updated so that
the initialization for struct A is done correctly for the new member.

We do have REV_INFO_INIT for "struct rev_info"

        #define REV_INFO_INIT { \
                .abbrev = DEFAULT_ABBREV, \
                .simplify_history = 1, \
                .pruning.flags.recursive = 1, \
                ...
                .expand_tabs_in_log_default = 8, \
        }

that does not allow any existing callers to leave it uninitialized
or get away by zero-initializing, so all the users must be using it
or the system before your patch is already buggy.

And we do have STRVEC_INIT that we must use in that initializer.

        extern const char *empty_strvec[];

        struct strvec {
                const char **v;
                size_t nr;
                size_t alloc;
        };

        #define STRVEC_INIT { \
                .v = empty_strvec, \
        }

So this step forgets to update revision.h to teach STRVEC_INIT on
the new rdiff_other_arg member.

Back when it was a random one-shot variable in range-diff, it might
not have mattered all that much, but now we have it as a proper
member of the struct, can we give it a name better than 'other_arg"?
Or is it the case that truly any random crap can be slurped into the
array and thrown back at "git log" without range-diff machinery
understanding what it is doing at all (which I would not be
surprised, as some parts of our code base is written in somewhat a
sloppy way)?

Thanks.

Re: [PATCH 1/2] revision: add rdiff_other_arg to rev_info

[Kristoffer Haugsbakk]

On Mon, Sep 22, 2025, at 23:58, Junio C Hamano wrote:
> kristofferhaugsbakk@fastmail.com writes:
>
>> git-format-patch(1) is supposed to treat Git notes the same between
>> notes output beneath the commit message and the notes output for the
>> range-diff.
>
> Is this an opinion, or are there things that existing pieces of code
> already do to achieve such a behaviour already?

What I mean is that

    Notes (...)

Beneath the commit message and

    ### Notes (...) ###

In the range-diff should be from the same namespaces. It shouldn’t be,
for example:

    Notes (presentation):

Beneath the commit message while the range-diff has:

    ### Notes (testing) ###
    ...
    ### Notes (scratchpad) ###

That’s the point of passing `--notes` to range-diff.

Am I missing something in the explanation?  The commit message might
need a rewrite.

>> diff --git a/revision.h b/revision.h
>> index 21e288c5baa..26c18a0934b 100644
>> --- a/revision.h
>> +++ b/revision.h
>> @@ -334,6 +334,7 @@ struct rev_info {
>>  	/* range-diff */
>>  	const char *rdiff1;
>>  	const char *rdiff2;
>> +	struct strvec rdiff_other_arg;
>>  	int creation_factor;
>>  	const char *rdiff_title;
>
> When embedding a struct A in a struct B, we should always make sure
> that initialization macro/function for struct B is updated so that
> the initialization for struct A is done correctly for the new member.
>
> We do have REV_INFO_INIT for "struct rev_info"
>
>         #define REV_INFO_INIT { \
>                 .abbrev = DEFAULT_ABBREV, \
>                 .simplify_history = 1, \
>                 .pruning.flags.recursive = 1, \
>                 ...
>                 .expand_tabs_in_log_default = 8, \
>         }
>
> that does not allow any existing callers to leave it uninitialized
> or get away by zero-initializing, so all the users must be using it
> or the system before your patch is already buggy.
>
> And we do have STRVEC_INIT that we must use in that initializer.
>
>         extern const char *empty_strvec[];
>
>         struct strvec {
>                 const char **v;
>                 size_t nr;
>                 size_t alloc;
>         };
>
>         #define STRVEC_INIT { \
>                 .v = empty_strvec, \
>         }
>
> So this step forgets to update revision.h to teach STRVEC_INIT on
> the new rdiff_other_arg member.

Thanks for the explanation.  I’ve added `.rdiff_other_arg = STRVEC_INIT
\` to `REV_INFO_INIT`.

> Back when it was a random one-shot variable in range-diff, it might
> not have mattered all that much, but now we have it as a proper
> member of the struct, can we give it a name better than 'other_arg"?

I’ve had that thought too.  But then I forgot what a better name
would be.

Could it be as simple as `log_arg` or `log_args`?

(This could be added as a preliminary patch)

`builtin/range-diff.c` uses `range_diff_options.other_arg` to pass
`--notes` but also (and quite recently[1]) to pass `--merges`.

    /* If `--diff-merges` was specified, imply `--merges` */

† 1: f8043236 (range-diff: optionally include merge commits' diffs in
    the analysis, 2024-12-16)

> Or is it the case that truly any random crap can be slurped into the
> array and thrown back at "git log" without range-diff machinery
> understanding what it is doing at all (which I would not be
> surprised, as some parts of our code base is written in somewhat a
> sloppy way)?

Well anything you throw into it will ultimately end up in the git-log(1)
child process in `range-diff.c:73`.[2]  But this doesn’t seem like a
problem given that all the arguments are “programmed” as constant
strings?

† 2: on ca2559c1 (The tenth batch, 2025-09-18)

Re: [PATCH 1/2] revision: add rdiff_other_arg to rev_info

[Junio C Hamano]

"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:

> On Mon, Sep 22, 2025, at 23:58, Junio C Hamano wrote:
>> kristofferhaugsbakk@fastmail.com writes:
>>
>>> git-format-patch(1) is supposed to treat Git notes the same between
>>> notes output beneath the commit message and the notes output for the
>>> range-diff.
>>
>> Is this an opinion, or are there things that existing pieces of code
>> already do to achieve such a behaviour already?
>
> What I mean is that
>
>     Notes (...)
>
> Beneath the commit message and
>
>     ### Notes (...) ###
>
> In the range-diff should be from the same namespaces. It shouldn’t be,
> for example:
>
>     Notes (presentation):
>
> Beneath the commit message while the range-diff has:
>
>     ### Notes (testing) ###
>     ...
>     ### Notes (scratchpad) ###
>
> That’s the point of passing `--notes` to range-diff.

OK.  So it is more like "range-diff is supposed to show comparison
of pairs of patches; if format-patch shows one set of notes after
three-dash lines in its output, range-diff invoked by format-patch
to compare its patches with another set of patches should also be
comparing patches generated with the same set of notes".  That makes
sense to me.

> Thanks for the explanation.  I’ve added `.rdiff_other_arg = STRVEC_INIT
> \` to `REV_INFO_INIT`.

Yup, I think I already have a fix-up patch mixed in your series in
the integration result I pushed out last night.

> Could it be as simple as `log_arg` or `log_args`?

Yeah, that is much better than "other" (where it is unclear what are
the "primary" things that "others" are in contrast).

Thanks.

Re: [PATCH 1/2] revision: add rdiff_other_arg to rev_info

[Kristoffer Haugsbakk]

On Tue, Sep 23, 2025, at 19:35, Junio C Hamano wrote:
> "Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:
>
>> On Mon, Sep 22, 2025, at 23:58, Junio C Hamano wrote:
>>> kristofferhaugsbakk@fastmail.com writes:
>>>
>>>> git-format-patch(1) is supposed to treat Git notes the same between
>>>> notes output beneath the commit message and the notes output for the
>>>> range-diff.
>>>
>>> Is this an opinion, or are there things that existing pieces of code
>>> already do to achieve such a behaviour already?
>>
>> What I mean is that
>> [snip]
>> That’s the point of passing `--notes` to range-diff.
>
> OK.  So it is more like "range-diff is supposed to show comparison
> of pairs of patches; if format-patch shows one set of notes after
> three-dash lines in its output, range-diff invoked by format-patch
> to compare its patches with another set of patches should also be
> comparing patches generated with the same set of notes".  That makes
> sense to me.

Exactly.

I might eventually send some drafts of better commit messages.

>> Thanks for the explanation.  I’ve added `.rdiff_other_arg = STRVEC_INIT
>> \` to `REV_INFO_INIT`.
>
> Yup, I think I already have a fix-up patch mixed in your series in
> the integration result I pushed out last night.

Oh yeah I saw that afterwards.  Which made me spot a mistake in my own
fixup... which was instructive. ;)

>> Could it be as simple as `log_arg` or `log_args`?
>
> Yeah, that is much better than "other" (where it is unclear what are
> the "primary" things that "others" are in contrast).

I remember looking at the code and having that realization: Oh, *other*
is *log*.  Huh.

... Maybe specifically `log_args` since it’s a `strvec`?  `git grep
'struct strvec'` seems to give me a lot of plural (style).

Re: [PATCH 1/2] revision: add rdiff_other_arg to rev_info

[Junio C Hamano]

"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:

>>> Could it be as simple as `log_arg` or `log_args`?
>>
>> Yeah, that is much better than "other" (where it is unclear what are
>> the "primary" things that "others" are in contrast).
>
> I remember looking at the code and having that realization: Oh, *other*
> is *log*.  Huh.
>
> ... Maybe specifically `log_args` since it’s a `strvec`?  `git grep
> 'struct strvec'` seems to give me a lot of plural (style).

If you were asking me about singular vs plural, sorry, I didn't even
realize that was the quesiton being asked.

My personal preference is to name arrays singular so that you can
name its 0th element by saying dog[0], not dogs[0].  "dog[1] and
dog[2] are friends" not dogs[1] and dogs[2].  An exception is when
most of the time you use the array as a single unit as a collection,
passing it around in the call chain, rarely addressing each individual
element.  I am OK to see such an array called plural (but of course,
singular names are always fine)..

An instance of "struct strvec" may fall into the same category as
the latter.  A single "struct strvec args" may be used as a
collection of arguments passed to the program .

So, log_args is fine by me.

[PATCH 2/2] format-patch: handle range-diff on notes correctly for single patches

[kristofferhaugsbakk]

From: Kristoffer Haugsbakk <code@khaugsbakk.name>

No `--[no-]notes` options are sent to the range-diff subprocess in
`range-diff.c` when making a single patch.  This means that you can get
different Git notes below the commit message and in the range-diff
part.  (See the previous commit for elaboration.)

Use the struct member that we introduced and populated in the
previous commit.

Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
---

Notes (series):
    I’ve tried to conform to 6caa96c2 (t3206: test_when_finished before
    dirtying operations, not after, 2024-08-06) in the test here.

 log-tree.c            |  3 ++-
 t/t3206-range-diff.sh | 16 +++++++++++++++-
 2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/log-tree.c b/log-tree.c
index 73d21f71764..831284288f9 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -718,7 +718,8 @@ static void show_diff_of_diff(struct rev_info *opt)
 			.creation_factor = opt->creation_factor,
 			.dual_color = 1,
 			.max_memory = RANGE_DIFF_MAX_MEMORY_DEFAULT,
-			.diffopt = &opts
+			.diffopt = &opts,
+			.other_arg = &opt->rdiff_other_arg
 		};
 
 		memcpy(&dq, &diff_queued_diff, sizeof(diff_queued_diff));
diff --git a/t/t3206-range-diff.sh b/t/t3206-range-diff.sh
index e091df6d01d..1e812df806b 100755
--- a/t/t3206-range-diff.sh
+++ b/t/t3206-range-diff.sh
@@ -707,7 +707,7 @@ test_expect_success 'format-patch --range-diff does not compare notes by default
 	! grep "note" 0000-*
 '
 
-test_expect_success 'format-patch --notes=custom --range-diff only compares custom notes' '
+test_expect_success 'format-patch --notes=custom --range-diff --cover-letter only compares custom notes' '
 	test_when_finished "git notes remove topic unmodified || :" &&
 	git notes add -m "topic note" topic &&
 	git notes add -m "unmodified note" unmodified &&
@@ -721,6 +721,20 @@ test_expect_success 'format-patch --notes=custom --range-diff only compares cust
 	! grep "## Notes ##" 0000-*
 '
 
+# --range-diff on a single commit requires --no-cover-letter
+test_expect_success 'format-patch --notes=custom --range-diff on single commit only compares custom notes' '
+	test_when_finished "git notes remove HEAD unmodified || :" &&
+	git notes add -m "topic note" HEAD &&
+	test_when_finished "git notes --ref=custom remove HEAD unmodified || :" &&
+	git notes add -m "unmodified note" unmodified &&
+	git notes --ref=custom add -m "topic note (custom)" HEAD &&
+	git notes --ref=custom add -m "unmodified note (custom)" unmodified &&
+	git format-patch --notes=custom --range-diff=$prev \
+		-1 --stdout >actual &&
+	test_grep "## Notes (custom) ##" actual &&
+	test_grep ! "## Notes ##" actual
+'
+
 test_expect_success 'format-patch --range-diff with --no-notes' '
 	test_when_finished "git notes remove topic unmodified || :" &&
 	git notes add -m "topic note" topic &&
-- 
2.51.0.270.gdb73cbc1bc1

Re: [PATCH 2/2] format-patch: handle range-diff on notes correctly for single patches

[Junio C Hamano]

kristofferhaugsbakk@fastmail.com writes:

> From: Kristoffer Haugsbakk <code@khaugsbakk.name>
>
> No `--[no-]notes` options are sent to the range-diff subprocess in
> `range-diff.c` when making a single patch.  This means that you can get
> different Git notes below the commit message and in the range-diff
> part.  (See the previous commit for elaboration.)

Would this also mean "range-diff --no-notes" would not have any
effect in squelching the note output in such a mode?  If so, perhaps
we should say not just "can get different Git notes" but "can get
notes even when you asked not to"?

> @@ -718,7 +718,8 @@ static void show_diff_of_diff(struct rev_info *opt)
>  			.creation_factor = opt->creation_factor,
>  			.dual_color = 1,
>  			.max_memory = RANGE_DIFF_MAX_MEMORY_DEFAULT,
> -			.diffopt = &opts
> +			.diffopt = &opts,
> +			.other_arg = &opt->rdiff_other_arg
>  		};
>  
>  		memcpy(&dq, &diff_queued_diff, sizeof(diff_queued_diff));
> diff --git a/t/t3206-range-diff.sh b/t/t3206-range-diff.sh
> index e091df6d01d..1e812df806b 100755
> --- a/t/t3206-range-diff.sh
> +++ b/t/t3206-range-diff.sh
> @@ -707,7 +707,7 @@ test_expect_success 'format-patch --range-diff does not compare notes by default
>  	! grep "note" 0000-*
>  '
>  
> -test_expect_success 'format-patch --notes=custom --range-diff only compares custom notes' '
> +test_expect_success 'format-patch --notes=custom --range-diff --cover-letter only compares custom notes' '
>  	test_when_finished "git notes remove topic unmodified || :" &&
>  	git notes add -m "topic note" topic &&
>  	git notes add -m "unmodified note" unmodified &&
> @@ -721,6 +721,20 @@ test_expect_success 'format-patch --notes=custom --range-diff only compares cust
>  	! grep "## Notes ##" 0000-*
>  '
>  
> +# --range-diff on a single commit requires --no-cover-letter
> +test_expect_success 'format-patch --notes=custom --range-diff on single commit only compares custom notes' '
> +	test_when_finished "git notes remove HEAD unmodified || :" &&
> +	git notes add -m "topic note" HEAD &&
> +	test_when_finished "git notes --ref=custom remove HEAD unmodified || :" &&
> +	git notes add -m "unmodified note" unmodified &&
> +	git notes --ref=custom add -m "topic note (custom)" HEAD &&
> +	git notes --ref=custom add -m "unmodified note (custom)" unmodified &&
> +	git format-patch --notes=custom --range-diff=$prev \
> +		-1 --stdout >actual &&
> +	test_grep "## Notes (custom) ##" actual &&
> +	test_grep ! "## Notes ##" actual
> +'

Sounds sensible.

>  test_expect_success 'format-patch --range-diff with --no-notes' '
>  	test_when_finished "git notes remove topic unmodified || :" &&
>  	git notes add -m "topic note" topic &&

Re: [PATCH 2/2] format-patch: handle range-diff on notes correctly for single patches

[Kristoffer Haugsbakk]

On Tue, Sep 23, 2025, at 00:01, Junio C Hamano wrote:
> kristofferhaugsbakk@fastmail.com writes:
>
>> From: Kristoffer Haugsbakk <code@khaugsbakk.name>
>>
>> No `--[no-]notes` options are sent to the range-diff subprocess in
>> `range-diff.c` when making a single patch.  This means that you can get
>> different Git notes below the commit message and in the range-diff
>> part.  (See the previous commit for elaboration.)
>
> Would this also mean "range-diff --no-notes" would not have any
> effect in squelching the note output in such a mode?

Do you mean `git format-patch ... --range-diff --no-notes`?  Yes,
`--no-notes` has no effect.  range-diff just does the default thing
which is `--show-notes-by-default` (act like git-log(1), which shows the
default notes namespace unless any `--[no-]notes` options are given (and
there are no such options in this case)).

> If so, perhaps we should say not just "can get different Git notes"
> but "can get notes even when you asked not to"?

I think “can get different Git notes” covers all possibilities, both too
many and too few.

But like the previous commit this one could maybe use a rewrite.

    No `--[no-]--notes` options are sent to the range-diff subprocess in
    `range-diff.c` when making a single patch.  This means that range-diff
    will handle Git notes like git-log(1).

    This is a problem when you ask to use certain notes, or none at all,
    since that set of notes will appear beneath the commit message but the
    range-diff will have whatever notes that git-log(1) would have given
    you.

That’s at least less dense.

>> @@ -718,7 +718,8 @@ static void show_diff_of_diff(struct rev_info *opt)
>> [snip]

Re: [PATCH 2/2] format-patch: handle range-diff on notes correctly for single patches

[Junio C Hamano]

"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:

> On Tue, Sep 23, 2025, at 00:01, Junio C Hamano wrote:
>> kristofferhaugsbakk@fastmail.com writes:
>>
>>> From: Kristoffer Haugsbakk <code@khaugsbakk.name>
>>>
>>> No `--[no-]notes` options are sent to the range-diff subprocess in
>>> `range-diff.c` when making a single patch.  This means that you can get
>>> different Git notes below the commit message and in the range-diff
>>> part.  (See the previous commit for elaboration.)
>>
>> Would this also mean "range-diff --no-notes" would not have any
>> effect in squelching the note output in such a mode?
>
> Do you mean `git format-patch ... --range-diff --no-notes`?  Yes,
> `--no-notes` has no effect.  range-diff just does the default thing
> which is `--show-notes-by-default` (act like git-log(1), which shows the
> default notes namespace unless any `--[no-]notes` options are given (and
> there are no such options in this case)).

And this change will fix that too, which is nice.

> But like the previous commit this one could maybe use a rewrite.
>
>     No `--[no-]--notes` options are sent to the range-diff subprocess in

"--notes" --> "notes", as a required single dash after negation is
already inside [] ;-)

>     `range-diff.c` when making a single patch.  This means that range-diff
>     will handle Git notes like git-log(1).
>
>     This is a problem when you ask to use certain notes, or none at all,
>     since that set of notes will appear beneath the commit message but the
>     range-diff will have whatever notes that git-log(1) would have given
>     you.
>
> That’s at least less dense.

Thanks.

[PATCH v2 0/3] format-patch: handle range-diff on notes correctly for single patches

[kristofferhaugsbakk]

From: Kristoffer Haugsbakk <code@khaugsbakk.name>

git-format-patch(1) does not handle Git notes correctly in the
range-diff output for single-commit series.  It reverts to the
default behavior of git-range-diff(1), which is to act like git-log(1).

Git notes can be added to patches where they go beneath the commit
message (similar to git-log(1)).  You can of course use any set of notes
ref names.  And the range-diff is supposed to use the same ref names.
This works for the case when you have a cover letter (for more than one
commit) but not when you have a single commit.

See patch 2/3 for a full explanation of the problem.

Fix that notes handling to always output the same notes (ref names) in
the two positions:

• beneath the commit message; and
• in the range diff.

Patch-by-patch:

1. Rename `other_arg` to `log_arg`
2. Refactor to use a new `rev_info` struct member
3. Use that in `log-tree.c` in order to solve the problem

§ Changes in v2

Mostly better commit messages.  Fix a mistake in the `rev_info` struct
handling.

Patch-by-patch (see notes on them for details):

1. (new) Better variable name
2. Rewrite commit message and fix mistake
3. Rewrite commit message by mostly stealing from patch 2/3

About the commit messages: the first one just jumped into the problem
without a proper introduction (see the note on patch 2/3).  Not clear
enough.  But I didn’t act on this review feedback:[1]

  “ Would this also mean "range-diff --no-notes" would not have any
    effect in squelching the note output in such a mode?  If so, perhaps
    we should say not just "can get different Git notes" but "can get
    notes even when you asked not to"?

🔗 1: https://lore.kernel.org/git/xmqqecryrvt6.fsf@gitster.g/

Since both commits in v1 already said `--[no-]notes`.

§ CC

Denton Liu wrote a commit mentioned in patch 1/3.  It’s been more years
than the recommended cutoff, but he has been active recently.

§ Link to the previous version

https://lore.kernel.org/git/cover.1758574974.git.code@khaugsbakk.name/

❦ ❦ ❦ ❦ ❦

(this means you can skip to the diffs)

§ How I Present Patch Series

Version: 1

The cover letter:

• Problem statement and solution
• (optional) Summary of what each commit/patch does
• Changes compared to the previous version
  • Note that all versions are not included
• (optional) “CC”/“Cc” which explains all or parts of the CC list
  • But some things are not noteworthy, like the standard practice of
    including previous-round respondents
• Link to the previous version
  • This is new.  I thought it was redundant but some people (like me!)
    use webapp email clients which are not that great for navigating
    among tree-like email threads.  So I was inspired by this practice
    which many others already use.
• I like including an interdiff in addition to the range diff if I can.
  They are just so convenient and complementary to the range diff.

Then each commit/patch might have Git notes with a `series` namespace
(ref name) These contain:

• Comments/questions to reviewers about my approach or statements made
  in the commit message.
• Lines starting with `v<version>:` which introduce a changelog for that
  version.  Lately (Sep 2025) these have been written in the “imperative
  mood”, like what is done for a commit message in this (Git) project.
  A bit strange, given that most others seem to use the more immediately
  natural past-tense.  But on the other hand: how many new contributors
  to this project use the wrong tense/mood in their commit messages?
  The Git project rule is not “natural”.  But I think it’s better
  nonetheless and worth the effort.

  (And it might be worth the effort in this context, too.  We will see.)
• ... But this kind of changelog might also be conducive to a bullet
  list of changes.  So I might either skip the previous point, do only a
  bullet point, or do both: a presentation and then the bullet points
  summarizing the presentation.
• Note that all `v<version>:` are kept between versions, which is not
  consistent with how I only have the “Changes” part for the previous
  version.
• `v<version>:` are ordered newest-to-oldest.

Kristoffer Haugsbakk (3):
  range-diff: rename other_arg to log_arg
  revision: add rdiff_log_arg to rev_info
  format-patch: handle range-diff on notes correctly for single patches

 builtin/log.c         |  7 +++----
 builtin/range-diff.c  | 16 ++++++++--------
 log-tree.c            |  3 ++-
 range-diff.c          | 10 +++++-----
 range-diff.h          |  2 +-
 revision.h            |  2 ++
 t/t3206-range-diff.sh | 16 +++++++++++++++-
 7 files changed, 36 insertions(+), 20 deletions(-)

Interdiff against v1:
diff --git a/builtin/log.c b/builtin/log.c
index 56dd9fbc057..9eff62ce111 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -1405,7 +1405,7 @@ static void make_cover_letter(struct rev_info *rev, int use_separate_file,
 			.dual_color = 1,
 			.max_memory = RANGE_DIFF_MAX_MEMORY_DEFAULT,
 			.diffopt = &opts,
-			.other_arg = &rev->rdiff_other_arg
+			.log_arg = &rev->rdiff_log_arg
 		};
 
 		repo_diff_setup(the_repository, &opts);
@@ -2325,7 +2325,7 @@ int cmd_format_patch(int argc,
 		rev.rdiff_title = diff_title(&rdiff_title, reroll_count,
 					     _("Range-diff:"),
 					     _("Range-diff against v%d:"));
-		get_notes_args(&(rev.rdiff_other_arg), &rev);
+		get_notes_args(&(rev.rdiff_log_arg), &rev);
 	}
 
 	/*
@@ -2485,7 +2485,7 @@ int cmd_format_patch(int argc,
 	rev.diffopt.no_free = 0;
 	release_revisions(&rev);
 	format_config_release(&cfg);
-	strvec_clear(&rev.rdiff_other_arg);
+	strvec_clear(&rev.rdiff_log_arg);
 	return 0;
 }
 
diff --git a/builtin/range-diff.c b/builtin/range-diff.c
index aafcc99b962..f88b40e3607 100644
--- a/builtin/range-diff.c
+++ b/builtin/range-diff.c
@@ -37,13 +37,13 @@ int cmd_range_diff(int argc,
 		   struct repository *repo UNUSED)
 {
 	struct diff_options diffopt = { NULL };
-	struct strvec other_arg = STRVEC_INIT;
+	struct strvec log_arg = STRVEC_INIT;
 	struct strvec diff_merges_arg = STRVEC_INIT;
 	struct range_diff_options range_diff_opts = {
 		.creation_factor = RANGE_DIFF_CREATION_FACTOR_DEFAULT,
 		.max_memory = RANGE_DIFF_MAX_MEMORY_DEFAULT,
 		.diffopt = &diffopt,
-		.other_arg = &other_arg
+		.log_arg = &log_arg
 	};
 	int simple_color = -1, left_only = 0, right_only = 0;
 	struct option range_diff_options[] = {
@@ -52,7 +52,7 @@ int cmd_range_diff(int argc,
 			    N_("percentage by which creation is weighted")),
 		OPT_BOOL(0, "no-dual-color", &simple_color,
 			    N_("use simple diff colors")),
-		OPT_PASSTHRU_ARGV(0, "notes", &other_arg,
+		OPT_PASSTHRU_ARGV(0, "notes", &log_arg,
 				  N_("notes"), N_("passed to 'git log'"),
 				  PARSE_OPT_OPTARG),
 		OPT_PASSTHRU_ARGV(0, "diff-merges", &diff_merges_arg,
@@ -92,7 +92,7 @@ int cmd_range_diff(int argc,
 	/* If `--diff-merges` was specified, imply `--merges` */
 	if (diff_merges_arg.nr) {
 		range_diff_opts.include_merges = 1;
-		strvec_pushv(&other_arg, diff_merges_arg.v);
+		strvec_pushv(&log_arg, diff_merges_arg.v);
 	}
 
 	for (i = 0; i < argc; i++)
@@ -124,7 +124,7 @@ int cmd_range_diff(int argc,
 		strbuf_addf(&range1, "%s..%s", argv[0], argv[1]);
 		strbuf_addf(&range2, "%s..%s", argv[0], argv[2]);
 
-		strvec_pushv(&other_arg, argv +
+		strvec_pushv(&log_arg, argv +
 			     (dash_dash < 0 ? 3 : dash_dash));
 	} else if (dash_dash == 2 ||
 		   (dash_dash < 0 && argc > 1 &&
@@ -144,7 +144,7 @@ int cmd_range_diff(int argc,
 		strbuf_addstr(&range1, argv[0]);
 		strbuf_addstr(&range2, argv[1]);
 
-		strvec_pushv(&other_arg, argv +
+		strvec_pushv(&log_arg, argv +
 			     (dash_dash < 0 ? 2 : dash_dash));
 	} else if (dash_dash == 1 ||
 		   (dash_dash < 0 && argc > 0 &&
@@ -175,7 +175,7 @@ int cmd_range_diff(int argc,
 		strbuf_addf(&range1, "%s..%.*s", b, a_len, a);
 		strbuf_addf(&range2, "%.*s..%s", a_len, a, b);
 
-		strvec_pushv(&other_arg, argv +
+		strvec_pushv(&log_arg, argv +
 			     (dash_dash < 0 ? 1 : dash_dash));
 	} else
 		usage_msg_opt(_("need two commit ranges"),
@@ -187,7 +187,7 @@ int cmd_range_diff(int argc,
 	range_diff_opts.right_only = right_only;
 	res = show_range_diff(range1.buf, range2.buf, &range_diff_opts);
 
-	strvec_clear(&other_arg);
+	strvec_clear(&log_arg);
 	strvec_clear(&diff_merges_arg);
 	strbuf_release(&range1);
 	strbuf_release(&range2);
diff --git a/log-tree.c b/log-tree.c
index 831284288f9..3d38c748e45 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -719,7 +719,7 @@ static void show_diff_of_diff(struct rev_info *opt)
 			.dual_color = 1,
 			.max_memory = RANGE_DIFF_MAX_MEMORY_DEFAULT,
 			.diffopt = &opts,
-			.other_arg = &opt->rdiff_other_arg
+			.log_arg = &opt->rdiff_log_arg
 		};
 
 		memcpy(&dq, &diff_queued_diff, sizeof(diff_queued_diff));
diff --git a/range-diff.c b/range-diff.c
index ca449a07693..57edff40a85 100644
--- a/range-diff.c
+++ b/range-diff.c
@@ -39,7 +39,7 @@ struct patch_util {
  * as struct object_id (will need to be free()d).
  */
 static int read_patches(const char *range, struct string_list *list,
-			const struct strvec *other_arg,
+			const struct strvec *log_arg,
 			unsigned int include_merges)
 {
 	struct child_process cp = CHILD_PROCESS_INIT;
@@ -69,8 +69,8 @@ static int read_patches(const char *range, struct string_list *list,
 	if (!include_merges)
 		strvec_push(&cp.args, "--no-merges");
 	strvec_push(&cp.args, range);
-	if (other_arg)
-		strvec_pushv(&cp.args, other_arg->v);
+	if (log_arg)
+		strvec_pushv(&cp.args, log_arg->v);
 	cp.out = -1;
 	cp.no_stdin = 1;
 	cp.git_cmd = 1;
@@ -594,9 +594,9 @@ int show_range_diff(const char *range1, const char *range2,
 	if (range_diff_opts->left_only && range_diff_opts->right_only)
 		res = error(_("options '%s' and '%s' cannot be used together"), "--left-only", "--right-only");
 
-	if (!res && read_patches(range1, &branch1, range_diff_opts->other_arg, include_merges))
+	if (!res && read_patches(range1, &branch1, range_diff_opts->log_arg, include_merges))
 		res = error(_("could not parse log for '%s'"), range1);
-	if (!res && read_patches(range2, &branch2, range_diff_opts->other_arg, include_merges))
+	if (!res && read_patches(range2, &branch2, range_diff_opts->log_arg, include_merges))
 		res = error(_("could not parse log for '%s'"), range2);
 
 	if (!res) {
diff --git a/range-diff.h b/range-diff.h
index 9d39818e349..9b70a80009e 100644
--- a/range-diff.h
+++ b/range-diff.h
@@ -23,7 +23,7 @@ struct range_diff_options {
 	unsigned include_merges:1;
 	size_t max_memory;
 	const struct diff_options *diffopt; /* may be NULL */
-	const struct strvec *other_arg; /* may be NULL */
+	const struct strvec *log_arg; /* may be NULL */
 };
 
 /*
diff --git a/revision.h b/revision.h
index 26c18a0934b..ce30570d86a 100644
--- a/revision.h
+++ b/revision.h
@@ -334,7 +334,7 @@ struct rev_info {
 	/* range-diff */
 	const char *rdiff1;
 	const char *rdiff2;
-	struct strvec rdiff_other_arg;
+	struct strvec rdiff_log_arg;
 	int creation_factor;
 	const char *rdiff_title;
 
@@ -411,6 +411,7 @@ struct rev_info {
 	.expand_tabs_in_log = -1, \
 	.commit_format = CMIT_FMT_DEFAULT, \
 	.expand_tabs_in_log_default = 8, \
+	.rdiff_log_arg = STRVEC_INIT, \
 }
 
 /**
Range-diff against v1:
-:  ----------- > 1:  bd037df14f5 range-diff: rename other_arg to log_arg
1:  bb065767336 ! 2:  d9419743773 revision: add rdiff_other_arg to rev_info
    @@ Metadata
     Author: Kristoffer Haugsbakk <code@khaugsbakk.name>
     
      ## Commit message ##
    -    revision: add rdiff_other_arg to rev_info
    -
    -    git-format-patch(1) needs to pass `--[no-]notes` options on to the
    -    range-diff subprocess in `range-diff.c`.  This is handled in `builtin/
    -    log.c` by the local variable `other_arg` in the case of multiple
    -    commits, but not in the single commit case where there is no cover
    -    letter and the range-diff is on that single resulting patch; the
    -    range-diff is then made in `log-tree.c`, whither `other_arg` has not
    -    been propagated.
    -
    -    git-format-patch(1) is supposed to treat Git notes the same between
    -    notes output beneath the commit message and the notes output for the
    -    range-diff.  But this lack of notes handling in `log-tree.c` breaks
    -    that expected behavior; range-diff notes handling for a single patch
    -    acts like a normal git-range-diff(1) invocation with regards to notes.
    -    You can, for example, end up with a patch where the note beneath the
    -    commit message has the correct notes namespace, but the range-diff has
    -    all the notes that are configured to be displayed by git-log(1).[1]
    -
    -    We need to fix this.  But first lay the groundwork by converting
    -    `other_arg` to a struct member; next we can simply use that member
    +    revision: add rdiff_log_arg to rev_info
    +
    +    git-format-patch(1) supports Git notes by showing them beneath the
    +    patch/commit message, similar to git-log(1). The command also supports
    +    showing those same notes ref names in the range diff output.
    +
    +    Note *the same* ref names; any Git notes options or configuration
    +    variables need to be handed off to the range-diff machinery. This works
    +    correctly in the case when the range diff is on the cover letter. But it
    +    does not work correctly when the output is a single patch with an
    +    embedded range diff.
    +
    +    Concretely, git-format-patch(1) needs to pass `--[no-]notes` options
    +    on to the range-diff subprocess in `range-diff.c`. This is handled in
    +    `builtin/log.c` by the local variable `log_arg` in the case of mul-
    +    tiple commits, but not in the single commit case where there is no
    +    cover letter and the range diff is embedded in the patch output; the
    +    range diff is then made in `log-tree.c`, whither `log_arg` has not
    +    been propagated. This means that the range-diff subprocess reverts
    +    to its default behavior, which is to act like git-log(1) w.r.t. notes.
    +
    +    We need to fix this. But first lay the groundwork by converting
    +    `log_arg` to a struct member; next we can simply use that member
         in `log-tree.c` without having to thread it from `builtin/log.c`.
     
         No functional changes.
     
    -    † 1: See the configuration variable `format.notes` for git-format-
    -         patch(1); c.f. `notes.displayRef` for git-log(1).  These two
    -         have nothing to do with each other.
    -
    +    Helped-by: Junio C Hamano <gitster@pobox.com>
         Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
     
     
      ## Notes (series) ##
    +    v2:
    +
    +    Rewrite the commit message.  The message jumps into the problem without
    +    setting the stage.  I think the problem should be presented for a future
    +    reader with only some basic prerequisite knowledge of this area; they
    +    might use git-format-patch(1), but they might not use Git notes *with*
    +    format-patch.[1]  For that reason, start with two paragraphs that pre-
    +    sent how notes are handled.  Then continue with the story in a format
    +    similar to v1.
    +
    +    Note that the different “range diff” and “range-diff” spellings are
    +    intentional.  “Range diff” here refers to the diff output while
    +    “range-diff” refers to the machinery that creates that output.
    +
    +    † 1: I don’t really see much Git notes use on patches on this mailing
    +         list.  And even less with non-default namespaces.  But in any case:
    +         the stage should be set properly even if regulars here *did* use
    +         format-patch notes a lot.
    +
    +    Also fix handling of struct-in-struct (helped by Junio).
    +
    +    • Rewrite the commit message
    +    • Fix struct-in-struct
    +    • (And) Reset author date.  I started this in June but the time
    +      investment is mostly from these last days.
    +
    +    v1:
    +
         There is also `other_arg` in `builtin/range-diff.c` but `rev_info` does
         not seem to be involved.
     
    @@ builtin/log.c: static void make_cover_letter(struct rev_info *rev, int use_separ
      		 * can be added later if deemed desirable.
      		 */
      		struct diff_options opts;
    --		struct strvec other_arg = STRVEC_INIT;
    +-		struct strvec log_arg = STRVEC_INIT;
      		struct range_diff_options range_diff_opts = {
      			.creation_factor = rev->creation_factor,
      			.dual_color = 1,
      			.max_memory = RANGE_DIFF_MAX_MEMORY_DEFAULT,
      			.diffopt = &opts,
    --			.other_arg = &other_arg
    -+			.other_arg = &rev->rdiff_other_arg
    +-			.log_arg = &log_arg
    ++			.log_arg = &rev->rdiff_log_arg
      		};
      
      		repo_diff_setup(the_repository, &opts);
    @@ builtin/log.c: static void make_cover_letter(struct rev_info *rev, int use_separ
      		opts.use_color = rev->diffopt.use_color;
      		diff_setup_done(&opts);
      		fprintf_ln(rev->diffopt.file, "%s", rev->rdiff_title);
    --		get_notes_args(&other_arg, rev);
    +-		get_notes_args(&log_arg, rev);
      		show_range_diff(rev->rdiff1, rev->rdiff2, &range_diff_opts);
    --		strvec_clear(&other_arg);
    +-		strvec_clear(&log_arg);
      	}
      }
      
    @@ builtin/log.c: int cmd_format_patch(int argc,
      		rev.rdiff_title = diff_title(&rdiff_title, reroll_count,
      					     _("Range-diff:"),
      					     _("Range-diff against v%d:"));
    -+		get_notes_args(&(rev.rdiff_other_arg), &rev);
    ++		get_notes_args(&(rev.rdiff_log_arg), &rev);
      	}
      
      	/*
    @@ builtin/log.c: int cmd_format_patch(int argc,
      	rev.diffopt.no_free = 0;
      	release_revisions(&rev);
      	format_config_release(&cfg);
    -+	strvec_clear(&rev.rdiff_other_arg);
    ++	strvec_clear(&rev.rdiff_log_arg);
      	return 0;
      }
      
    @@ revision.h: struct rev_info {
      	/* range-diff */
      	const char *rdiff1;
      	const char *rdiff2;
    -+	struct strvec rdiff_other_arg;
    ++	struct strvec rdiff_log_arg;
      	int creation_factor;
      	const char *rdiff_title;
      
    +@@ revision.h: struct rev_info {
    + 	.expand_tabs_in_log = -1, \
    + 	.commit_format = CMIT_FMT_DEFAULT, \
    + 	.expand_tabs_in_log_default = 8, \
    ++	.rdiff_log_arg = STRVEC_INIT, \
    + }
    + 
    + /**
2:  7f2487af433 ! 3:  2be637081d4 format-patch: handle range-diff on notes correctly for single patches
    @@ Metadata
      ## Commit message ##
         format-patch: handle range-diff on notes correctly for single patches
     
    -    No `--[no-]notes` options are sent to the range-diff subprocess in
    -    `range-diff.c` when making a single patch.  This means that you can get
    -    different Git notes below the commit message and in the range-diff
    -    part.  (See the previous commit for elaboration.)
    +    (The two next paragraphs are taken from the previous commit.)
     
    -    Use the struct member that we introduced and populated in the
    +    git-format-patch(1) supports Git notes by showing them beneath the
    +    patch/commit message, similar to git-log(1). The command also supports
    +    showing those same notes ref names in the range diff output.
    +
    +    Note *the same* ref names; any Git notes options or configuration
    +    variables need to be handed off to the range-diff machinery. This works
    +    correctly in the case when the range diff is on the cover letter. But it
    +    does not work correctly when the output is a single patch with an
    +    embedded range diff.
    +
    +    Concretely, git-format-patch(1) needs to pass `--[no-]notes` options on
    +    to the range-diff subprocess in `range-diff.c`. Range diffs for single-
    +    commit series are handled in `log-tree.c`. But `log-tree.c` had no
    +    access to any `log_arg` variable before we added it to `rev_info` in the
         previous commit.
     
    +    Use that new struct member to fix this inconsistency.
    +
         Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
     
     
      ## Notes (series) ##
    +    v1:
    +
         I’ve tried to conform to 6caa96c2 (t3206: test_when_finished before
         dirtying operations, not after, 2024-08-06) in the test here.
     
    @@ log-tree.c: static void show_diff_of_diff(struct rev_info *opt)
      			.max_memory = RANGE_DIFF_MAX_MEMORY_DEFAULT,
     -			.diffopt = &opts
     +			.diffopt = &opts,
    -+			.other_arg = &opt->rdiff_other_arg
    ++			.log_arg = &opt->rdiff_log_arg
      		};
      
      		memcpy(&dq, &diff_queued_diff, sizeof(diff_queued_diff));

base-commit: ca2559c1d630eb4f04cdee2328aaf1c768907a9e
-- 
2.51.0.311.g9b2318464ce

[PATCH v2 1/3] range-diff: rename other_arg to log_arg

[kristofferhaugsbakk]

From: Kristoffer Haugsbakk <code@khaugsbakk.name>

Rename `other_arg` to `log_arg` in `range_diff_options` and
related places.

“Other argument” comes from bd361918 (range-diff: pass through --notes
to `git log`, 2019-11-20) which introduced Git notes handling to
git-range-diff(1) by passing that option on to git-log(1). And that kind
of name might be fine in a local context. However, it was initially
spread among multiple files, and is now[1] part of the
`range_diff_options` struct. It is, prima facie, difficult to guess what
“other” means, especially when just looking at the struct.

But with a little reading we find out that it is used for `--[no-]notes`
and `--diff-merges`, which are both passed on to git-log(1). We should
just rename it to reflect this role; `log_arg` suggests, along with the
`strvec` type, that it is used to pass extra arguments to git-log(1).

† 1: since f1ce6c19 (range-diff: combine all options in a single data
     structure, 2021-02-05)

Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
---

Notes (series):
    v2 (new):
    
    Add a preliminary commit after discussing the `other_arg` name with
    Junio.
    
      “ Back when it was a random one-shot variable in range-diff, it might
        not have mattered all that much, but now we have it as a proper
        member of the struct, can we give it a name better than 'other_arg"?
    
    Link: https://lore.kernel.org/git/xmqqikharvyl.fsf@gitster.g/
    
    Later:
    
      “ My personal preference is to name arrays singular so that you can
        name its 0th element by saying dog[0], not dogs[0].  "dog[1] and
        dog[2] are friends" not dogs[1] and dogs[2].  An exception is when
        most of the time you use the array as a single unit as a collection,
        passing it around in the call chain, rarely addressing each individual
        element.  I am OK to see such an array called plural (but of course,
        singular names are always fine)..
    
    And I chose singular to personal preference in this context (the use
    etc. for this kind of variable).

 builtin/log.c        |  8 ++++----
 builtin/range-diff.c | 16 ++++++++--------
 range-diff.c         | 10 +++++-----
 range-diff.h         |  2 +-
 4 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/builtin/log.c b/builtin/log.c
index 5f552d14c0f..131512ac1af 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -1400,13 +1400,13 @@ static void make_cover_letter(struct rev_info *rev, int use_separate_file,
 		 * can be added later if deemed desirable.
 		 */
 		struct diff_options opts;
-		struct strvec other_arg = STRVEC_INIT;
+		struct strvec log_arg = STRVEC_INIT;
 		struct range_diff_options range_diff_opts = {
 			.creation_factor = rev->creation_factor,
 			.dual_color = 1,
 			.max_memory = RANGE_DIFF_MAX_MEMORY_DEFAULT,
 			.diffopt = &opts,
-			.other_arg = &other_arg
+			.log_arg = &log_arg
 		};
 
 		repo_diff_setup(the_repository, &opts);
@@ -1414,9 +1414,9 @@ static void make_cover_letter(struct rev_info *rev, int use_separate_file,
 		opts.use_color = rev->diffopt.use_color;
 		diff_setup_done(&opts);
 		fprintf_ln(rev->diffopt.file, "%s", rev->rdiff_title);
-		get_notes_args(&other_arg, rev);
+		get_notes_args(&log_arg, rev);
 		show_range_diff(rev->rdiff1, rev->rdiff2, &range_diff_opts);
-		strvec_clear(&other_arg);
+		strvec_clear(&log_arg);
 	}
 }
 
diff --git a/builtin/range-diff.c b/builtin/range-diff.c
index aafcc99b962..f88b40e3607 100644
--- a/builtin/range-diff.c
+++ b/builtin/range-diff.c
@@ -37,13 +37,13 @@ int cmd_range_diff(int argc,
 		   struct repository *repo UNUSED)
 {
 	struct diff_options diffopt = { NULL };
-	struct strvec other_arg = STRVEC_INIT;
+	struct strvec log_arg = STRVEC_INIT;
 	struct strvec diff_merges_arg = STRVEC_INIT;
 	struct range_diff_options range_diff_opts = {
 		.creation_factor = RANGE_DIFF_CREATION_FACTOR_DEFAULT,
 		.max_memory = RANGE_DIFF_MAX_MEMORY_DEFAULT,
 		.diffopt = &diffopt,
-		.other_arg = &other_arg
+		.log_arg = &log_arg
 	};
 	int simple_color = -1, left_only = 0, right_only = 0;
 	struct option range_diff_options[] = {
@@ -52,7 +52,7 @@ int cmd_range_diff(int argc,
 			    N_("percentage by which creation is weighted")),
 		OPT_BOOL(0, "no-dual-color", &simple_color,
 			    N_("use simple diff colors")),
-		OPT_PASSTHRU_ARGV(0, "notes", &other_arg,
+		OPT_PASSTHRU_ARGV(0, "notes", &log_arg,
 				  N_("notes"), N_("passed to 'git log'"),
 				  PARSE_OPT_OPTARG),
 		OPT_PASSTHRU_ARGV(0, "diff-merges", &diff_merges_arg,
@@ -92,7 +92,7 @@ int cmd_range_diff(int argc,
 	/* If `--diff-merges` was specified, imply `--merges` */
 	if (diff_merges_arg.nr) {
 		range_diff_opts.include_merges = 1;
-		strvec_pushv(&other_arg, diff_merges_arg.v);
+		strvec_pushv(&log_arg, diff_merges_arg.v);
 	}
 
 	for (i = 0; i < argc; i++)
@@ -124,7 +124,7 @@ int cmd_range_diff(int argc,
 		strbuf_addf(&range1, "%s..%s", argv[0], argv[1]);
 		strbuf_addf(&range2, "%s..%s", argv[0], argv[2]);
 
-		strvec_pushv(&other_arg, argv +
+		strvec_pushv(&log_arg, argv +
 			     (dash_dash < 0 ? 3 : dash_dash));
 	} else if (dash_dash == 2 ||
 		   (dash_dash < 0 && argc > 1 &&
@@ -144,7 +144,7 @@ int cmd_range_diff(int argc,
 		strbuf_addstr(&range1, argv[0]);
 		strbuf_addstr(&range2, argv[1]);
 
-		strvec_pushv(&other_arg, argv +
+		strvec_pushv(&log_arg, argv +
 			     (dash_dash < 0 ? 2 : dash_dash));
 	} else if (dash_dash == 1 ||
 		   (dash_dash < 0 && argc > 0 &&
@@ -175,7 +175,7 @@ int cmd_range_diff(int argc,
 		strbuf_addf(&range1, "%s..%.*s", b, a_len, a);
 		strbuf_addf(&range2, "%.*s..%s", a_len, a, b);
 
-		strvec_pushv(&other_arg, argv +
+		strvec_pushv(&log_arg, argv +
 			     (dash_dash < 0 ? 1 : dash_dash));
 	} else
 		usage_msg_opt(_("need two commit ranges"),
@@ -187,7 +187,7 @@ int cmd_range_diff(int argc,
 	range_diff_opts.right_only = right_only;
 	res = show_range_diff(range1.buf, range2.buf, &range_diff_opts);
 
-	strvec_clear(&other_arg);
+	strvec_clear(&log_arg);
 	strvec_clear(&diff_merges_arg);
 	strbuf_release(&range1);
 	strbuf_release(&range2);
diff --git a/range-diff.c b/range-diff.c
index ca449a07693..57edff40a85 100644
--- a/range-diff.c
+++ b/range-diff.c
@@ -39,7 +39,7 @@ struct patch_util {
  * as struct object_id (will need to be free()d).
  */
 static int read_patches(const char *range, struct string_list *list,
-			const struct strvec *other_arg,
+			const struct strvec *log_arg,
 			unsigned int include_merges)
 {
 	struct child_process cp = CHILD_PROCESS_INIT;
@@ -69,8 +69,8 @@ static int read_patches(const char *range, struct string_list *list,
 	if (!include_merges)
 		strvec_push(&cp.args, "--no-merges");
 	strvec_push(&cp.args, range);
-	if (other_arg)
-		strvec_pushv(&cp.args, other_arg->v);
+	if (log_arg)
+		strvec_pushv(&cp.args, log_arg->v);
 	cp.out = -1;
 	cp.no_stdin = 1;
 	cp.git_cmd = 1;
@@ -594,9 +594,9 @@ int show_range_diff(const char *range1, const char *range2,
 	if (range_diff_opts->left_only && range_diff_opts->right_only)
 		res = error(_("options '%s' and '%s' cannot be used together"), "--left-only", "--right-only");
 
-	if (!res && read_patches(range1, &branch1, range_diff_opts->other_arg, include_merges))
+	if (!res && read_patches(range1, &branch1, range_diff_opts->log_arg, include_merges))
 		res = error(_("could not parse log for '%s'"), range1);
-	if (!res && read_patches(range2, &branch2, range_diff_opts->other_arg, include_merges))
+	if (!res && read_patches(range2, &branch2, range_diff_opts->log_arg, include_merges))
 		res = error(_("could not parse log for '%s'"), range2);
 
 	if (!res) {
diff --git a/range-diff.h b/range-diff.h
index 9d39818e349..9b70a80009e 100644
--- a/range-diff.h
+++ b/range-diff.h
@@ -23,7 +23,7 @@ struct range_diff_options {
 	unsigned include_merges:1;
 	size_t max_memory;
 	const struct diff_options *diffopt; /* may be NULL */
-	const struct strvec *other_arg; /* may be NULL */
+	const struct strvec *log_arg; /* may be NULL */
 };
 
 /*
-- 
2.51.0.311.g9b2318464ce

[PATCH v2 2/3] revision: add rdiff_log_arg to rev_info

[kristofferhaugsbakk]

From: Kristoffer Haugsbakk <code@khaugsbakk.name>

git-format-patch(1) supports Git notes by showing them beneath the
patch/commit message, similar to git-log(1). The command also supports
showing those same notes ref names in the range diff output.

Note *the same* ref names; any Git notes options or configuration
variables need to be handed off to the range-diff machinery. This works
correctly in the case when the range diff is on the cover letter. But it
does not work correctly when the output is a single patch with an
embedded range diff.

Concretely, git-format-patch(1) needs to pass `--[no-]notes` options
on to the range-diff subprocess in `range-diff.c`. This is handled in
`builtin/log.c` by the local variable `log_arg` in the case of mul-
tiple commits, but not in the single commit case where there is no
cover letter and the range diff is embedded in the patch output; the
range diff is then made in `log-tree.c`, whither `log_arg` has not
been propagated. This means that the range-diff subprocess reverts
to its default behavior, which is to act like git-log(1) w.r.t. notes.

We need to fix this. But first lay the groundwork by converting
`log_arg` to a struct member; next we can simply use that member
in `log-tree.c` without having to thread it from `builtin/log.c`.

No functional changes.

Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
---

Notes (series):
    v2:
    
    Rewrite the commit message.  The message jumps into the problem without
    setting the stage.  I think the problem should be presented for a future
    reader with only some basic prerequisite knowledge of this area; they
    might use git-format-patch(1), but they might not use Git notes *with*
    format-patch.[1]  For that reason, start with two paragraphs that pre-
    sent how notes are handled.  Then continue with the story in a format
    similar to v1.
    
    Note that the different “range diff” and “range-diff” spellings are
    intentional.  “Range diff” here refers to the diff output while
    “range-diff” refers to the machinery that creates that output.
    
    † 1: I don’t really see much Git notes use on patches on this mailing
         list.  And even less with non-default namespaces.  But in any case:
         the stage should be set properly even if regulars here *did* use
         format-patch notes a lot.
    
    Also fix handling of struct-in-struct (helped by Junio).
    
    • Rewrite the commit message
    • Fix struct-in-struct
    • (And) Reset author date.  I started this in June but the time
      investment is mostly from these last days.
    
    v1:
    
    There is also `other_arg` in `builtin/range-diff.c` but `rev_info` does
    not seem to be involved.

 builtin/log.c | 7 +++----
 revision.h    | 2 ++
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/builtin/log.c b/builtin/log.c
index 131512ac1af..9eff62ce111 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -1400,13 +1400,12 @@ static void make_cover_letter(struct rev_info *rev, int use_separate_file,
 		 * can be added later if deemed desirable.
 		 */
 		struct diff_options opts;
-		struct strvec log_arg = STRVEC_INIT;
 		struct range_diff_options range_diff_opts = {
 			.creation_factor = rev->creation_factor,
 			.dual_color = 1,
 			.max_memory = RANGE_DIFF_MAX_MEMORY_DEFAULT,
 			.diffopt = &opts,
-			.log_arg = &log_arg
+			.log_arg = &rev->rdiff_log_arg
 		};
 
 		repo_diff_setup(the_repository, &opts);
@@ -1414,9 +1413,7 @@ static void make_cover_letter(struct rev_info *rev, int use_separate_file,
 		opts.use_color = rev->diffopt.use_color;
 		diff_setup_done(&opts);
 		fprintf_ln(rev->diffopt.file, "%s", rev->rdiff_title);
-		get_notes_args(&log_arg, rev);
 		show_range_diff(rev->rdiff1, rev->rdiff2, &range_diff_opts);
-		strvec_clear(&log_arg);
 	}
 }
 
@@ -2328,6 +2325,7 @@ int cmd_format_patch(int argc,
 		rev.rdiff_title = diff_title(&rdiff_title, reroll_count,
 					     _("Range-diff:"),
 					     _("Range-diff against v%d:"));
+		get_notes_args(&(rev.rdiff_log_arg), &rev);
 	}
 
 	/*
@@ -2487,6 +2485,7 @@ int cmd_format_patch(int argc,
 	rev.diffopt.no_free = 0;
 	release_revisions(&rev);
 	format_config_release(&cfg);
+	strvec_clear(&rev.rdiff_log_arg);
 	return 0;
 }
 
diff --git a/revision.h b/revision.h
index 21e288c5baa..ce30570d86a 100644
--- a/revision.h
+++ b/revision.h
@@ -334,6 +334,7 @@ struct rev_info {
 	/* range-diff */
 	const char *rdiff1;
 	const char *rdiff2;
+	struct strvec rdiff_log_arg;
 	int creation_factor;
 	const char *rdiff_title;
 
@@ -410,6 +411,7 @@ struct rev_info {
 	.expand_tabs_in_log = -1, \
 	.commit_format = CMIT_FMT_DEFAULT, \
 	.expand_tabs_in_log_default = 8, \
+	.rdiff_log_arg = STRVEC_INIT, \
 }
 
 /**
-- 
2.51.0.311.g9b2318464ce

[PATCH v2 3/3] format-patch: handle range-diff on notes correctly for single patches

[kristofferhaugsbakk]

From: Kristoffer Haugsbakk <code@khaugsbakk.name>

(The two next paragraphs are taken from the previous commit.)

git-format-patch(1) supports Git notes by showing them beneath the
patch/commit message, similar to git-log(1). The command also supports
showing those same notes ref names in the range diff output.

Note *the same* ref names; any Git notes options or configuration
variables need to be handed off to the range-diff machinery. This works
correctly in the case when the range diff is on the cover letter. But it
does not work correctly when the output is a single patch with an
embedded range diff.

Concretely, git-format-patch(1) needs to pass `--[no-]notes` options on
to the range-diff subprocess in `range-diff.c`. Range diffs for single-
commit series are handled in `log-tree.c`. But `log-tree.c` had no
access to any `log_arg` variable before we added it to `rev_info` in the
previous commit.

Use that new struct member to fix this inconsistency.

Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name>
---

Notes (series):
    v1:
    
    I’ve tried to conform to 6caa96c2 (t3206: test_when_finished before
    dirtying operations, not after, 2024-08-06) in the test here.

 log-tree.c            |  3 ++-
 t/t3206-range-diff.sh | 16 +++++++++++++++-
 2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/log-tree.c b/log-tree.c
index 73d21f71764..3d38c748e45 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -718,7 +718,8 @@ static void show_diff_of_diff(struct rev_info *opt)
 			.creation_factor = opt->creation_factor,
 			.dual_color = 1,
 			.max_memory = RANGE_DIFF_MAX_MEMORY_DEFAULT,
-			.diffopt = &opts
+			.diffopt = &opts,
+			.log_arg = &opt->rdiff_log_arg
 		};
 
 		memcpy(&dq, &diff_queued_diff, sizeof(diff_queued_diff));
diff --git a/t/t3206-range-diff.sh b/t/t3206-range-diff.sh
index e091df6d01d..1e812df806b 100755
--- a/t/t3206-range-diff.sh
+++ b/t/t3206-range-diff.sh
@@ -707,7 +707,7 @@ test_expect_success 'format-patch --range-diff does not compare notes by default
 	! grep "note" 0000-*
 '
 
-test_expect_success 'format-patch --notes=custom --range-diff only compares custom notes' '
+test_expect_success 'format-patch --notes=custom --range-diff --cover-letter only compares custom notes' '
 	test_when_finished "git notes remove topic unmodified || :" &&
 	git notes add -m "topic note" topic &&
 	git notes add -m "unmodified note" unmodified &&
@@ -721,6 +721,20 @@ test_expect_success 'format-patch --notes=custom --range-diff only compares cust
 	! grep "## Notes ##" 0000-*
 '
 
+# --range-diff on a single commit requires --no-cover-letter
+test_expect_success 'format-patch --notes=custom --range-diff on single commit only compares custom notes' '
+	test_when_finished "git notes remove HEAD unmodified || :" &&
+	git notes add -m "topic note" HEAD &&
+	test_when_finished "git notes --ref=custom remove HEAD unmodified || :" &&
+	git notes add -m "unmodified note" unmodified &&
+	git notes --ref=custom add -m "topic note (custom)" HEAD &&
+	git notes --ref=custom add -m "unmodified note (custom)" unmodified &&
+	git format-patch --notes=custom --range-diff=$prev \
+		-1 --stdout >actual &&
+	test_grep "## Notes (custom) ##" actual &&
+	test_grep ! "## Notes ##" actual
+'
+
 test_expect_success 'format-patch --range-diff with --no-notes' '
 	test_when_finished "git notes remove topic unmodified || :" &&
 	git notes add -m "topic note" topic &&
-- 
2.51.0.311.g9b2318464ce