Skip to contentSkip to conversation

format-patch: handle range-diff on notes correctly for single patches

PATCH Superseded [email protected] 2 participants 15 messages Sep 22, 2025 – Sep 25, 2025

lore
Share & tools
lore
#0 lore raw

cover format-patch: handle range-diff on notes correctly for single patches

From: Kristoffer Haugsbakk <[email protected]>

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

Signature · 1 line
2.51.0.270.gdb73cbc1bc1
#1 lore raw

PATCH 1/2 revision: add rdiff_other_arg to rev_info

From: Kristoffer Haugsbakk <[email protected]>

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.

---

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(-)
builtin/log.c +3 -4
index 5f552d14c0f..56dd9fbc057 100644
@@ -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;
 }
 
revision.h +1 -0
index 21e288c5baa..26c18a0934b 100644
@@ -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;
 
Signature · 1 line
2.51.0.270.gdb73cbc1bc1
#7 lore raw

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

In reply to [email protected]

From: Kristoffer Haugsbakk <[email protected]>

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.

---

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(-)
log-tree.c +2 -1
index 73d21f71764..831284288f9 100644
@@ -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));
t/t3206-range-diff.sh +15 -1
index e091df6d01d..1e812df806b 100755
@@ -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 &&
Signature · 1 line
2.51.0.270.gdb73cbc1bc1
#2 lore raw

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

In reply to [email protected]
Quoted 3 lines · [email protected] 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?

revision.h struct rev_info { · line 339

Quoted 11 lines
revision.h +1 -0
index 21e288c5baa..26c18a0934b 100644
@@ -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.

#8 lore raw
In reply to [email protected]
Quoted 6 lines · [email protected] writes:

From: Kristoffer Haugsbakk <[email protected]>

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"?

Quoted 30 lines
log-tree.c +2 -1
@@ -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));
t/t3206-range-diff.sh +4 -1
index e091df6d01d..1e812df806b 100755
@@ -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 || :" &&

t/t3206-range-diff.sh test_expect_success 'format-patch --notes=custom --range-diff only compares cust · line 736

Quoted 10 lines
t/t3206-range-diff.sh +10 -0
+	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.

Quoted 3 lines
t/t3206-range-diff.sh +0 -0
 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 &&
#3 lore raw

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

In reply to Junio C Hamano
Quoted 8 lines · Junio C Hamano
Quoted 3 lines · [email protected] 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.

Quoted 44 lines

revision.h struct rev_info { · line 339

Quoted 11 lines
revision.h +1 -0
index 21e288c5baa..26c18a0934b 100644
@@ -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, \
        }
Quoted 2 lines

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.

Quoted 3 lines

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)
Quoted 5 lines

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)

#9 lore raw
In reply to Junio C Hamano
Quoted 11 lines · Junio C Hamano
Quoted 6 lines · [email protected] writes:

From: Kristoffer Haugsbakk <[email protected]>

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)).

Quoted 2 lines

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.

Quoted 2 lines
Quoted 2 lines
(quoted diff) +0 -0
@@ -718,7 +718,8 @@ static void show_diff_of_diff(struct rev_info *opt)
[snip]
#4 lore raw

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

In reply to Kristoffer Haugsbakk
Quoted 23 lines · Kristoffer Haugsbakk
Quoted 8 lines · Junio C Hamano
Quoted 3 lines · [email protected] 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):

Quoted 7 lines

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.

Quoted 2 lines

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.

Quoted 1 line

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.

#5 lore raw

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

Quoted 16 lines · Junio C Hamano
Quoted 7 lines · Kristoffer Haugsbakk
Quoted 6 lines · Junio C Hamano
Quoted 3 lines · [email protected] 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.

Quoted 6 lines
Quoted 2 lines

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.

Quoted 6 lines

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.

Quoted 5 lines
Quoted 2 lines

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. ;)

Quoted 4 lines
Quoted 1 line

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).

#6 lore raw

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

Quoted 10 lines · Kristoffer Haugsbakk
Quoted 4 lines
Quoted 1 line

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.

#10 lore raw
In reply to Kristoffer Haugsbakk
Quoted 10 lines · Kristoffer Haugsbakk
Quoted 9 lines · Junio C Hamano
Quoted 6 lines · [email protected] writes:

From: Kristoffer Haugsbakk <[email protected]>

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.)

Quoted 8 lines
Quoted 2 lines

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.

Quoted 3 lines

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 [] ;-)

Quoted 9 lines

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.

#11 lore raw

v2 cover format-patch: handle range-diff on notes correctly for single patches

In reply to [email protected]

From: Kristoffer Haugsbakk <[email protected]>

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/[email protected]/

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/[email protected]/

❦ ❦ ❦ ❦ ❦

(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:

builtin/log.c +3 -3
index 56dd9fbc057..9eff62ce111 100644
@@ -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;
 }
 
builtin/range-diff.c +8 -8
index aafcc99b962..f88b40e3607 100644
@@ -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);
log-tree.c +1 -1
index 831284288f9..3d38c748e45 100644
@@ -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));
range-diff.c +5 -5
index ca449a07693..57edff40a85 100644
@@ -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) {
range-diff.h +1 -1
index 9d39818e349..9b70a80009e 100644
@@ -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 */
 };
 
 /*
revision.h +2 -1
index 26c18a0934b..ce30570d86a 100644
@@ -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 <[email protected]>

## 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 <[email protected]>

## 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.
+

## 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

Signature · 1 line
2.51.0.311.g9b2318464ce
#12 lore raw

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

From: Kristoffer Haugsbakk <[email protected]>

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)

---

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"?

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(-)
builtin/log.c +4 -4
index 5f552d14c0f..131512ac1af 100644
@@ -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);
 	}
 }
 
builtin/range-diff.c +8 -8
index aafcc99b962..f88b40e3607 100644
@@ -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);
range-diff.c +5 -5
index ca449a07693..57edff40a85 100644
@@ -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) {
range-diff.h +1 -1
index 9d39818e349..9b70a80009e 100644
@@ -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 */
 };
 
 /*
Signature · 1 line
2.51.0.311.g9b2318464ce
#13 lore raw

PATCH v2 2/3 revision: add rdiff_log_arg to rev_info

In reply to [email protected]

From: Kristoffer Haugsbakk <[email protected]>

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.

---

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(-)
builtin/log.c +3 -4
index 131512ac1af..9eff62ce111 100644
@@ -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;
 }
 
revision.h +2 -0
index 21e288c5baa..ce30570d86a 100644
@@ -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, \
 }
 
 /**
Signature · 1 line
2.51.0.311.g9b2318464ce
#14 lore raw

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

In reply to [email protected]

From: Kristoffer Haugsbakk <[email protected]>

(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.

---

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(-)
log-tree.c +2 -1
index 73d21f71764..3d38c748e45 100644
@@ -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));
t/t3206-range-diff.sh +15 -1
index e091df6d01d..1e812df806b 100755
@@ -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 &&
Signature · 1 line
2.51.0.311.g9b2318464ce